What's a well formed project look like?

Project schedules are produced all the time in the course of managing a project. They are used in their Gantt form, their PERT form, as presentation graphics for executive meetings, resource loaded reports to show staffing plans, and sometimes as budget planing documents. These documents are presented as "plans" for projects. They are also the source of much of the problems found in project management.

What makes a good project schedule?

This is probably the wrong question. The question should be what makes a good network of activities from which the project schedule can be derived?

1. No widows or orphans - every task has a start and an end. It has some explicit reason for being there. "Why does this task start?" "What does this task deliver to the project?" are questions that need to be asked. There are only two tasks, start (authorization to proceed), end (period of performance complete) that don't have a start or an end respectively
2. Have as few hard constraints as possible - "as soon as possible" should be the predominate constraint. "Start no earlier than" and "Finish no later than" are the only two constraints that should be used. There are others of course but they will simply foul up the assessment of the network, introduce "bugs" in the plan and cause the backward pass of Microsoft Project's Critical Path engine to produce wrong numbers.
3. Negative or large positive slack - once all the tasks are connected in a network, any negative slack indicates where the schedule is already late. Large positive slack indicates that the plan is not realistic since the specific task is not located near its needed outcome.
4. A critical path or paths - indicates where the plan can get in trouble. There are many myths about the evils of critical path. Most of that discussion comes from folks who haven't worked in a business domain that relied on critical path analysis. A critical path approach to Extreme Programming software development doesn't make much sense. A critical path to launching a mission Mars does. The critical path changes all the time, so those who rail against "a" critical path probably haven't been on a project that use CPM.
5. Planning buffers - although I'm not a great fan of the Theory of Constraints as presented by some zealots, having planning buffers embedded in the schedule is common practice in aerospace and construction - and should be in software development. These buffers are explicit schedule margin maintained by the project manager and senior management in the same way "management reserve" is maintained for funding.
6. Resource planning - this is difficult to do in some domains. Detailed resource planning "can" be useful if the plan requires specific skill sets. Embedding resources in MSFT Project requires care, so a resource loaded schedule should be developed only if needed - at least in the early cycles of planning. This, along with cost analysis is usually the domain of finance in large projects, so sharing the load with the finance folks helps keep things straight.
7. Cost planning - the "basis of estimate" approach to cost loading the schedule is the starting point. Assigning budget to work packages is the first step. Detailed cost planning, like detailed resource planning is a "sporty" business for the uninitiated.
8. PERT Estimates - developing a 3-point estimate for the durations of tasks is a useful process IF the critical path and probabilistic estimate of completion is needed. In the absence of these specific needs a probabilistic risk analysis does provide information for larger projects.
9. A Work Breakdown Structure - there is much confusing about the role of the WBS. In government contracting executed under the control of IPPD (Integrated Product and Process Development) with Integrated Product Teams (IPT), the WBS is the cost collection vehicle. The WBS can also be used to describe the breakdown of work in the absence of the IMP/IMS approach (Integrated Master Plan / Integrated Master Schedule). The WBS is one of the theological discussions in project management, so be careful not to get wrapped around the axle about the role of the WBS.

There are dozens of other elements of a good plan (network of tasks), but a BLOG is too small a window to present them. Maybe a book chapter!