Tips for Effective Project Planning Keep your plan at as high of a level as possible Don’t use more detail than you have the ability to follow-up on. Except for milestones and enabling deliverables, avoid having too many tasks with durations less than your follow-up frequency. Use checklists when appropriate to keep track of things like gate and launch deliverables.
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 help as you work to bring in the end date. Focus on getting the dependencies right. Don’t let other people enter tasks for someone else without obtaining the task owners buy-in. Whenever possible, try to capture the evolution through the DOE, Design Of Experiments, 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 available to 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 Könige, Easter Monday, May Day (Labour Day), Ascension Day, Whitsun Day (Pentecost Monday), Reunion (Day of German Unity)
0573660975432c5e06673c1a660a5a05.doc Page 1 of 4 GDG Solutions When assigning resources, use the person who has the responsibility for 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 leveling resources and collecting costs.
Avoid using task duration's that are less than the review / update frequency Don’t have more detail than can be maintained. Don’t have more detail than requirements stability merits.
Don't treat gate reviews as converging / diverging nodes in the schedule 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. Don’t 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 & utilization throughout the project Don’t 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 the product development process to develop, manage & maintain the plans
0573660975432c5e06673c1a660a5a05.doc Page 2 of 4 GDG Solutions Recommended PM best practices
1) Develop schedules using network diagrams or PERT charts with a focus 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. Too often, a “center of the universe” mentality is used where functions act as if everyone knows what they need and what they deliver, without the necessary communication and confirmation meeting being held. A properly constructed network diagram or PERT chart presents a visual image of how you are going to achieve the objective, and makes the goal highly visible. Network diagrams or PERT charts show how different functions contributions enable the goal. A properly constructed network diagram or PERT chart show what enabling deliverables you need, from whom, and what deliverables you are providing, and to whom. Tasks that don’t 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 interlocking deliverables 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 it correctly MS Project was written for "capital" project management, NOT "technical" project management. MS Project is very easy to misuse. “Just because the Ferrari can go 200 mph, doesn’t mean you have to go 200 mph.” MS Project allows over constrained tasks MS Project allows hard coding of dates on tasks with a predecessor without warning you that the hard coded date rules over the predecessor. MS Project has no ability to assess PM best practices. MS Project doesn’t warn you about how many danglers you have (tasks without successors). . If a task doesn’t enable another task or deliverable, unless it is an enabling deliverable for another plan, why are you doing it? MS Project doesn’t warn you about the number of dependencies you have that are not F-S (finish to start) or contain lags. . Non F-S dependencies will come in as you execute the plan and need to recover slips in the schedule.
0573660975432c5e06673c1a660a5a05.doc Page 3 of 4 GDG Solutions 0573660975432c5e06673c1a660a5a05.doc Page 4 of 4 GDG Solutions