Let’s Start at the Start, and Finish at the Finish!

Start at The Start, and Finish at the Finish! One of the greatest challenges in managing projects is engaging the full project life cycle. We too-often see practitioners who believe that the “real project” starts at execution of a preconceived solution. These folks seem to believe that the business case, stakeholder engagement, clear and measurable requirements, are a gift from above. Also often missing are solution delivery staging, alternative solutions and approaches, and other essential-to-success actions.

Similarly, many project teams escape to other projects late in the project, before success is even evident. Crucial actions remain, such as defect correction, warranty period adjustments, and follow-on change orders. These all increase the return on investment of successful projects, and proof that you met the business need, and supported your sponsor’s strategy.

starting and ending projects in the middleGiven this syndrome, these sadly misinformed project managers and teams should chart their projects’ more like the one at left. After all, they are starting and ending their part of the project in the middle!

Starting and ending projects correctly
Meanwhile the more-savvy project teams follow a more effective, more success-oriented approach. This starts at the start, and finishes at the finish. It is shown at the right.

Why do less-effective teams skip the most important parts?


It’s not all their fault. In years past, one PM standard lamented that project managers were too often appointed after the success-determining actions were completed. This lament was expressed in place of correcting that fatal flaw. Of course, managers and executives are at least partly at fault. If the project manager is not present, then someone else must complete this work. In all our PM methods, we assign at least a temporary project manager at initial concept. Then we assign our Project Sponsor responsibility to demonstrate, after the project, that the project achieved its intended business needs.

Other Reasons

There are other reasons why too many “project managers” fail to start at the start and finish at the finish. Those reasons may include:

  • Those processes and results (sometimes called outputs) were not part of the bodies of knowledge they are trying to follow. At least, last time they read them, they weren’t.
  • They may be “doers,” rather than “thinkers;” and worse, their managers may also be. I remember the early days (1960s-1970s) of Information Technology projects (then called DP). The frequent assertion then: If you weren’t writing code by the second week of the project, you weren’t working hard enough!
  • As we note in our workshops, which often include project managers and team members, program managers, managers and executives: The presence of fear, risk and pressure adds adrenalin to the most primitive part of one’s brain. This causes most people to be doing rather than thinking, and solitary rather than teaming. Thus, they focus on obvious solutions versus creative ones. Have you experienced this syndrome?
  • And, while there are many more reasons, here is a very interesting one: The majority of project managers, as they grow into their role, build their competences beginning late in the life cycle. They then progress to the early life-cycle competences. And some never progress earlier than detailed design of a preconceived solution.

By the way, most Agile methods (with some exceptions) are late-life-cycle solutions. Of course, for over three decades, early life cycle practices, have all been hallmarks of fully competent project managers. These include rapid initial planning, intensive planning sessions for requirements elicitation, and incremental, iterative delivery of results.

How do I know if they’re doing the right early stuff?

If you have just been offered a project to take over, there are a handful of results you should look for in the project documentation. You did find documentation, didn’t you? For internal projects (projects that involve bidding on contracts have many more) those results include:

  • Initial project concept or request, with the intended business benefit, as expressed by the requester.
  • Preliminary analysis, by a project manager or business analyst, with measures or indicators of scope, and early cost estimates. And, look for talent requirements, preliminary timelines, risk analysis, areas of benefits (to be quantified later) and prioritization factors.
  • Stakeholder engagement actions, such as a problem or opportunity analysis, to discover more of the (iceberg-style) hidden scope earlier. Assess the “as is” of impacted organization units, and assess the extent of organizational change the project will involve.
  • A statement of the initial project approach, including in-house or out-house considerations, buy or build, big bang or incremental. Look at staging as sequential or concurrent (concurrent is faster, but requires more talent), and other execution considerations.
  • Preliminary business requirements, as prioritized by business unit managers, mapped to the problem or opportunity analysis. Make sure they are traceable through solution selection, testing, validation and delivery.
  • Given the above, be sure to look for alternative solutions. It was Peter Drucker, who said in the 1970s, “if you only have one clear solution, you don’t understand the problem.”

Of course, organization managers must be mature enough to flex early-set constraints such as time and cost. This is essential because early discovery of added scope is good news, rather than bad. How would your projects score on this short list? Would you be willing to take on a project that is missing most of them? Have you done so in the past?

Perhaps this is why so many project managers—and teams—experience fear, risk and pressure in projects!

The plane truth

When you travel in a plane, which parts of your journey do you think are the ones that require the most pilot skill? The take-off? Cruising at altitude (when the plane is often on auto-pilot)? The landing? Of course, there are incidents at altitude where pilot skill is essential. but it is largely the take-off and landing that is most demanding.

And so it is with competent and performing project managers. The early and late project activities not only require the greatest talent (including interpersonal skills and leadership) and experience, they also contribute most (when performed competently) to project and business success.

Your takeaway: If you and your teams are not already doing so, it is time for you, in your projects, to Start at the Start, and Finish at the Finish!

Your Comments?