project planning tips

7/29/2019 Project Planning Tips

1/4

Tips for Effective Project Planning

Keep your plan at as high of a level as possible Dont use more detail than you have the ability to follow-up on.

Except for milestones and enabling deliverables, avoid having too many tasks withdurations less than your follow-up frequency.

Use checklists when appropriate to keep track of things like gate and launchdeliverables.

Don't get hung up on having everything in one plan Technical development, functional specific & documentation can be in different plans

Use interlocking deliverables between plans.

Just because the SW can handle all resources & costs doesn't mean it's appropriate.

When developing all plans: Try to use task descriptions that contain both a verb and a noun.

Use language that is meaningful to the people that are executing the plan.

When developing technical schedules / plans: Use multi-functional teams whenever possible.

Obtaining buy-in to the logic / PERT diagram before entering task duration's will helpas you work to bring in the end date. Focus on getting the dependencies right.

Dont let other people enter tasks for someone else without obtaining the taskowners buy-in.

Whenever possible, try to capture the evolution through the DOE, Design OfExperiments, process. (See: Generic DOE plan)

Use of assessment points at appropriate times minimizes risk.

Resource dependencies are just as important as technical dependencies.

Persistence in keeping the plan in sync with what's really happening pays off.

When developing documentation schedules / plans: Track milestones for starting, draft availability and final version complete.

Estimate duration's based on the % of time a person will be availableto work on the task Take into account experience & learning curve.

Avoid using individual resource calendars.

Ask how long a task will take, given their current workload.

Allow time in the plan for: Unit build, ship & install Data analysis & report / presentation preparation

Weeks containing holidays

Worldwide: New Years Day, Good Friday, Easter & Christmas

In the US: Memorial Day, July 4th, Labor Day & Thanksgiving

In other countries (ie: Germany): Heilige Drei Knige, Easter Monday, May Day(Labour Day), Ascension Day, Whitsun Day (Pentecost Monday), Reunion (Dayof German Unity)

171120796.doc Page 1 of 4 GDG Solutions


2/4

When assigning resources, use the person who has the responsibilityfor delivering the results Preferably the supervisor or manager that you would turn to for status during a staff

meeting or gate review.

Even though it has the capability, MS Project is not the right tool for levelingresources and collecting costs.

Avoid using task duration's that are less than the review / updatefrequency Dont have more detail than can be maintained.

Dont have more detail than requirements stability merits.

Don't treat gate reviews as converging / diverging nodes in theschedule In reality, very few activities are held up as you wait for a gate review.

Gate reviews are times of assessment, and hopefully celebration.

Gate reviews generally result in the plan being adjusted, not overhauled.

Risk abatement countermeasures are identified and addressed.

Pay special attention to shared resources Follow-up more frequently if possible.

Dont forget the lead time to schedule test facilities.

These types of resources also have other customers they need to satisfy too.

Respect the complexity of the PM software you are using There is a fine line between PM SW being a tool for you, and you being a slave to

the SW.

The difference between a good plan and a bad plan is the PM process, not the report

or chart the SW can generate.

Pay attention to the development machine allocation & utilizationthroughout the project Dont forget Alpha, Beta, Demo & Trade Show machines.

These are typically early units with a high UMC, so keep the number down.

Use someone who is technically competent & understands theproduct development process to develop, manage & maintain theplans



3/4

Recommended PM best practices

1) Develop schedules using network diagrams or PERT charts with afocus on dependencies between tasks(See: Pert vs Gantt Views) Functional silo planning asks, what do I do? Multi-functional dependency thinking

asks, what do I deliver, and to whom and what do I need, and from whom. Toooften, a center of the universe mentality is used where functions act as if everyoneknows what they need and what they deliver, without the necessary communicationand confirmation meeting being held.

A properly constructed network diagram or PERT chart presents a visual image ofhow you are going to achieve the objective, and makes the goal highly visible.

Network diagrams or PERT charts show how different functions contributions enablethe goal.

A properly constructed network diagram or PERT chart show what enablingdeliverables you need, from whom, and what deliverables you are providing, and towhom. Tasks that dont enable anything else are quickly identified and questioned.

2) Track status against the plan using the "Task Starts" process The "Task Starts" process provides focus on what needs to be done now.

The "Task Starts" process can provide a process control like chart.

The "Task Starts" process accelerates the "student syndrome".

The "Task Starts" process makes problems visible sooner.

"One seldom finishes on time what one does not start on time."

3) All plans need a system integration focus and contain interlockingdeliverables The sooner we find system integration problems, the better.

Interlocking deliverables give us visibility to enabling deliverables, both in and out. Interlocking deliverables enable the ability to create a hierarchy of plans.

4) When using MS Project (or any other PM SW) you need to use itcorrectly

MS Project was written for "capital" project management, NOT "technical" projectmanagement.

MS Project is very easy to misuse.

Just because the Ferrari can go 200 mph, doesnt mean you have to go 200mph.

MS Project allows over constrained tasks

MS Project allows hard coding of dates on tasks with a predecessor withoutwarning you that the hard coded date rules over the predecessor.

MS Project has no ability to assess PM best practices.

MS Project doesnt warn you about how many danglers you have (tasks withoutsuccessors).

If a task doesnt enable another task or deliverable, unless it is an enablingdeliverable for another plan, why are you doing it?

MS Project doesnt warn you about the number of dependencies you have thatare not F-S (finish to start) or contain lags.



4/4

Non F-S dependencies will come in as you execute the plan and need torecover slips in the schedule.


project planning tips

Documents