Newsletter Volume 1 No.4

Volume 1, No. 4

“Helping You Accelerate Your High-Tech Development Projects”

Welcome to the ANGOTTI PRODUCT DEVELOPMENT email newsletter!

The goal of this newsletter is to help you accelerate your development projects by sharing some of the many tips, techniques and strategies we’ve honed during our two decades of providing high-tech consulting services.

This issue discusses the part that one of the most significant, and overlooked parts of a project – generating a detailed development project plan. This is often cited as one of the most important, and overlooked parts of a project in determining the successful outcome of a high technology development project.

“WE ALWAYS CREATE A PLAN FOR OUR PROJECTS”

I am often surprised by the situation I find at many organizations in that the formal engineering development plan is either non-existent, or seriously out of date. Hence it does not represent the work in progress currently. Yet the management and team members often believe they have one. It is felt that everyone already understands what is to be done, so the “one pager” put together by Product Marketing and/or Engineering should do the trick. Besides, making plans is just a waste of valuable time, they never really work out anyway and they interfere with the “real work”.

For the purpose of this article, I refer to a Product Development plan for a project, often, the critical one for a high tech organization. There should also be a Formal “Project Plan”, that includes all aspects of what is to be done from definition through to launch. On the other hand, the engineering project plan is the dominant “critical path” and often consumes the majority of the budget on a high tech project. It is what “makes or breaks” it.

A REAL PLAN IS WRITTEN

Upper management, Project Managers and the team should be committed to creating a detailed, written, plan for the project. Plans are crucial to getting things done within a reasonable time and budget. Even a small project, but especially a large one, can not be monitored or controlled without a written plan. Some organizations just produce one at the beginning of the project, or because upper management wants one for a meeting. After this, they go into the desk drawer to remain there until there is the project is in trouble.

A PLAN IS A COMBINED EFFORT

Ideally, the persons working on the project create this plan, along with the project manager. They then work with upper management to create a workable one in the business context. These plans need to be detailed enough, but not so detailed as to obscure what is going on. It is a combined effort of “top down” and “bottom up”. Neither approach is perfect, and both are a compromise.

This is the place where the most project management judgement is concentrated, both before the project begins, and as it progresses. It is best to consider a few alternatives plan models, instead of just jumping in on one, as is often the case.

A GOOD PLACE TO START

A good first step in a plan is to add an initial set of tasks to create the formal set of specifications for the product, and the critical block diagrams, flow diagrams, etc. This assures that there is a real target for the tasks ahead. Then, model the balance of the plan on one that has worked before.

Begin with the basic project steps and milestones, followed by a few example schedules illustrating strategies that can overcome the most serious project risks. These “top down” cases are then shown to the working team engineers and support persons. The team then breaks down the tasks even further, and gives estimates to be integrated upward into the final plan.

IMPROVING TEAM ESTIMATES

It is critical that the project manager, and the persons that work on a project, have a practical approach to estimating. Often, team
members have little skill in estimating the time and costs to complete a project task. They often don’t get good feedback from past projects, except in the form of “you are always late” or “you are too optimistic”. Very few organizations have formal methods to feedback to team members the quality of their estimates.

If team members are uncertain about how long a task will take, a good practise is to break a specific task down into lower component task steps, until good estimates can be made. This detail need not be “rolled up” into the plan, but it is always a useful exercise.

A STATISTICAL APPROACH

A statistical approach can be very helpful in illustrating the risk contained in a schedule. A good statistical method is to use a best,
nominal, and worst case scenarios in the “bottom up” estimating. These can then RSS’d (Root Sum Squared) together to be used to create a statistical measure of time and cost risk in a project. From this analysis, a two or three sigma, nominal, best and worst case plan can be made. For reference, see the paper on my website by Dr. Kissinger on “Step by Step Project Management” and my companion “RSS Calculator”.

Be sure to approach the cost of items bought from vendors in the same manner to round out the project estimate. This is especially true if large portions of the project are outsourced.

CLOSING THE LOOP

Next, this detailed, “bottom up”, plan is presented to top management. They comment on the plan, and the plan is reviewed by both groups several times until it is considered ready for adoption. This is where the common complaint for planning frequently arises. Engineering resources complain the management wants things “too fast” for good engineering, and management complains that engineering wants to take “too long” to make good business sense. There is room here on both sides for good compromise.

BUY IN

When the selected and updated “top down” plan reaches the point that it is ready for adoption, the results are formally fed back to the critical resource persons that created the detailed “bottom up” plan. This process gives them a final chance to make changes and become more committed to the final program. Without this “buy in”, the project can have significant built in problems from the very start.

WORK THE PLAN

Now it is time to “work the plan” and check progress periodically, as well as apply and redirect resources as needed. It is often good practise to formally review the plan at least each two weeks for longer projects. For shorter projects, weekly reviews are in order.