notebook

Tracking the rate of completion of work

How often have you ever wanted to know how fast you are getting through work on a program or project? In the software development world you often want to track the rate of completion of features or the rate of completion of bugs. Similar examples can be found in other industries such as the semiconductor industry.

fastProject supports this with a function called completionTrend and is easy to setup. completionTrend can track multiple groups, so the first step is to identify the number of different groups you want to track the rate of completion and give the them names, e.g. high priority features and low priority features or high priority bugs and low priority bugs, etc.There is no limit to the number of groups you can have.

The next step is to then simply assign that name to the relevant task in the schedule and the Target date you want to have them completed by. That's all there is to it.

If I only had 5-minutes, what would I want to know about your new product development project?

Recently I read a marketing requirements document (MRD) for a sophisticated new mission critical software product for enterprise customers. Like most of these MRD's it was over 200 pages and it was full of technical information which seemed to be placed in the document to illustrate the vast knowledge of the writer, rather than to serve any purpose for the reader.

Most of it was blah, blah, blah to me. I think this is true of the other readers, but no one said anything for fear of reporting the obvious... that the document was of little value to helping the development team set the boundary conditions for a successful program.

scheduleAnalyzer: ranking best practices

When developing scheduleAnalyzer we incorporated a group of best practices that directly affect the quality of a schedule. We find ourselves fixing client schedules regularly so that we could get a valid critical path, to enable us to pull-in and accelerate the project. We needed a way to automate this process, which is what lead to scheduleAnalyzer download scheduleAnalyzer ranking model. These weighting values were incorporated into the scoring system in scheduleAnalyzer.

We knew that some of the practices were more important than others with respect to the goal we were trying to achieve which was: To create a schedule to enable the project to be accelerated. We then looked at the decision criteria that could be used to evaluate each best practice and how each practice contributed to achieving the goal.

scheduleAnalyzer: "A plan is only a common base for change"

scheduleAnalyzer is just one tool of many that can be used to improve the quality of a schedule. It was designed to enable our clients to do their own analysis as a way of checking for common mistakes. More than anything, it was designed as a learning tool and a way of getting schedules all up to a minimum quality baseline across multiple projects within an organization.

scheduleAnalyzer: Analyze your schedule for best practices

We just released a new version of scheduleAnalyzer. It is a tool to evaluate MS Project schedules and identify common problems based on best practices of fast teams. It is designed to be used in the context of continuous improvement of both the project manager's skills and the quality of schedule information.

The purpose of creating and maintaining a critical path schedule is to be able to accurately predict a project's end date.

A proper schedule should have a free flowing critical path form the start of the project through to the end of the project. The longest contiguous path (i.e. the critical path) is used to accelerate and pull-in the schedule. Without a proper critical path, schedule acceleration is difficult to model and using the information to predict project completion is even more problematic.

Root causes of poor RTTM performance

Our research team is developing the framework for our second best practice study. The first study was initiated 17 years ago and has been continually added to though hundreds of consulting engagements around the world during this time frame.

Our focus, with this research, were the factors that drove fast development of technology products, and those that also exceeded customer expectations (i.e. right-products at the right-time).

We were looking at how to get FTTM (fast-time-to-market) results on strategic products, which inevitably meant that other products in the portfolio suffered (i.e. robbed Peter to pay Paul).

"I am not trying to evaluate your performance, I am just trying to locate it!"

My post yesterday (Assessing your new product "portfolio system") was meant as a drill-down into the portfolio management process. A set of questions used to diagnose the as-is status of a current system.

I think that w.r.t portfolio, it is less about the root causes of failure, but rather in trying to locate any formal system at all (i.e. "I am not trying to evaluate your performance, I am just trying to locate it!").

A common root cause of a failed portfolio system is that the fuzzy-front-end is an unmanaged process in most companies. It just happens in an ad-hoc way, with multiple stakeholders trying to influence it in their direction (i.e. the classic engineering versus marketing conflict). With no single point of leadership.

At the end of the day, new product development teams see the collective inefficiencies of this poorly managed process when they have too many projects, not enough time, and half the resources they need to be effective. The result is late products or the wrong products.

No one is accountable since no one owns the process. Profitability suffers and executive management looks to "market forces" or "strong competitive factors" to blame, but in many cases the problem start closer to home!

Assessing your new product "portfolio system"

We are developing a diagnostic assessment tool to evaluate current "portfolio systems." By this I mean the process management teams use to determine which new products make it into the product development pipeline and which get killed.

This diagram lists a few top level questions we ask clients in order to gain an understanding of the system they use to manage their new product portfolio. This list is evolving over time with ongoing use and refinement. Suggestions welcome.