Japanese Approach to Strategy Deployment

Methods for strategy deployment in Japan embrace workforce participation and includes processes in the discussion. ...

... "the Japanese Hoshin is concerned with both results and process while using two-way employee communication, and allows their active participation. " ...

Via The Manila Times: Hoshin Kanri

Project Cancellations

Good stewardship of projects will place stage gates and hurdles into the delivery process, which offers companies an opportunity to reevaluate further investment given current conditions and the strategic outlook. However, here's some tips for reading the situation ahead of stage-gates. ...

... "It's a normal and natural part of the project management process to have a few go/no-go points in the plan or to have milestones that must be met for the project to be allowed to continue. " ...

Via TechRepublic: Signs that your project is about to be cut

Communities of Interest Improve Project Performance

DOD sees project performance benefits after engaging stakeholder communities in the process. Benefits accrue when the community provides input and shares the change among its membership. ...

... "As part of its network-centric data strategy, DOD requires that COIs are part of all of its major projects. And the directive is clearly beginning to pay off ... " ...

Via Government Computer News: Community of Interest, COI

Perform to Schedule

Performance to schedule is critical to manufacturing processes. This same discipline needs to extend to project schedules. However, not all projects and tasks are as repeatable as manufacturing steps. And, people aren't machines. ...

... "At the manufacturing level, processes are expected to be adhered to with clockwork precision to meet defined deadlines. With over 6 lakh cars a year from three assembly lines in Gurgaon and 1 lakh from a plant in Manesar, the shop floors need to produce exactly to a plan. " ...

Via InfoWorld Nederland: IT on wheels

Project Forecasting: More Lessons from Driving

A while ago, I entered a post about the importance of staying tuned in, drawing an analogy to driving. Well, another driving analogy had occured to me, this time about the need to focus on remaining time.

Let's put it this way. If you're driving from Philadelphia to New York City and you're at the entrance to the New Jersey Turnpike, what percent complete are you on your trip?

Some of you may guess certain percentages based on distance, but that's as foolish as basing project percent complete on the percent of budget or time that's been spent, without regard for work accomplished.

The quick answer is: Who cares what percent complete we are? What we really should be concerned with is how much time is left, assuming we care about what time we arrive to begin with.

But let's say that we DO care (i.e. schedule is a priority for us, as opposed to some other success factor). How can we measure whether we'll be there on time?

Simply using a percent complete tells us nothing. It's too subjective. What we need to know how much time is remaining. And that will depend on how fast you're going, how many miles are left, what barriers may arise (i.e. road closings, flat tires, etc.), how many stops you make, and a number of other variables. It's no different for projects.

For project schedule control, capturing percent complete is too theoretical, so that's not of much use to us. And capturing time spent tells us very little, except perhaps how long it took us to do prior work, which may not be an accurate indicator of future work. Besides, we can probably determine future work estimates more accurately through expert opinion and/or statistical sampling (combined with good planning).

Of course, there's no harm in entering time spent as long as people are disciplined to always include time remaining. Then a percent-complete can be calculated based on that. But the percent-complete itself is not a leading indicator, so is still of questionable value.

If we focus instead on time remaining at the task level, and combine that with barrier removal, risk planning, and regular reforecasts, we'd have much better control over whether we "arrive on time."

We can improve our ability to estimate in the future by capturing lessons learned, doing spot checks, and using the information to create project schedule templates and checklists, so future projects can avoid running over the same potholes.

Some may say, "Oh, we still need the percent-complete for Earned Value calculations."

Do we really? By putting a dollar amount to the time remaining, we can solve the same problem in a simpler fashion, answering the question: How much is it going to cost us to complete this project and what's our estimated time to arrival?

Just some food for thought. See my followup post on Project Forecasting and Uncertainty as well.

Lesson Learned: The Importance of Followup

I was just reading an article about how the DHS (Department of Human Services) never followed up on 17 of the 36 recommendations that were made after child deaths under their watch. The recommendations were supposed to lead to policy changes.

It's a harsh reminder that, while it's nice to gather lessons learned at the end of a project, the lessons are entirely useless if they're "put back in the drawer" with the rest of the project archives.

Lessons learned are supposed to either lead to permanent policy changes or changes in future similar projects. It's important to identify any actions to be taken as a result of lessons learned, along with a clear owner and target date. Ideally, project audits should look to see that lessons are followed up on.

This was an extreme case, but it should serve as a reminder to all of us who are associated with fostering best practice project management processes.

Process Maturity Made Easy

I was going to report on an interesting article by Michael Hammer in the April Harvard Business Review, but I see Dave Garrett at Gantthead has beaten me to the punch. I've included a link below to the Gantthead article.

Basically, the Hammer article is about the new Process and Enterprise Maturity Model (PEMM) that Hammer has been working on with the Phoenix Consortium. It's the result of a research project they undertook to develop a process implementation roadmap.

In the Gantthead article below, Garrett has some helpful links, as well as a summary of the five process enablers and the four enterprise capabilities in the PEMM framework.

Let's see, with PEMM along with the Business Analysts Body of Knowledge (recently announced by the International Institute of Business Analysis - IIBA) , there should be plenty of complimentary models to go along with the PMBOK and ITIL. This should keep consultants busy for a while.

Meanwhile, here's the Gantthead link...

Beyond CMMI... PEMM

The Enemy of Simplicity: The Thud Factor

We've all heard about the benefits of simplicity, whether in our processes, our communication, or in our objectives. In all its forms, simplicity is a way to reduce confusion, boost morale, and encourage speed and flexibility. In fact, simplicity, speed, and flexibility are three of the "Six Winning Principles" I wrote about in Napoleon on Project Management (the other three being exactitude, character, and moral force).

But there's a lurking enemy of simplicity, and it often goes unnoticed. It can be found in the motives of individuals creating the processes, communications, or objectives. I'm talking about job protection. I don't mean the blatant kind that results from grandiose thinking, egotism or turf wars. It's much more subtle than that.

It can happen if an individual or department is placed in charge of creating a process or devising a plan. Or it can happen if a consulting company is brought in to do a study or offer advice. Common sense says that these people, while not necessarily devious, will hesitate to come up with anything too simple, lest they feel they're not doing their job. The result is often something that is way more detailed, complex, and expensive than it needs to be.

What can we do about it? We need to be very aware of motives and rewards, and make sure we don't consiously or unconciously reward people for complexity. We need to send a message that the shortest, simplest way to meet the goal wins (even offering incentives if possible). This can avoid what many consultants jokingly refer to as "the thud factor"----the customer's perception of the value of the service as judged by how much of a noise the report makes when it's dropped on their desk.

Whether it's a consulting company, a PMO, an internal process center, or a project team, we need to find a way to head off the thud factor and insure simplicity. We can do this by understanding motives; sending the right message; insisting on brief, simple reports; and creating the right reward system.