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

PM Commentary by Stacy Goff, ProjectExperts CEO.
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, solution delivery staging, alternative solutions and approaches, and other essential-to-success actions are a gift from above.

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, follow-on change orders (chargeable, of course), that increase the return on investment of successful projects, and proof that you met the business need, and supported your sponsor’s strategy.

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

Meanwhile the more-savvy project teams (or luckier teams, as the case may be) follow the more effective, more success-oriented approach, which starts at the start, and finishes at the finish. This 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 many of 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 (ProjectExperts) PM methods, we assign at least a temporary project manager at initial concept, and then assign our Project Sponsor responsibility to demonstrate, after the project, that the project achieved its intended business needs.

There are other reasons why too many “project managers” (who are often just execution 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, causing most people to be doing rather than thinking, solitary rather than teaming, and focusing 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 build their competences beginning late in the life cycle, 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 such as rapid initial planning, intensive planning sessions for requirements elicitation, and incremental, iterative delivery of results, have all been hallmarks of fully competent project managers.

How do I know if they’re doing the right early stuff?
Whether you are a stakeholder in a project, a manager of project managers, a new project manager who has just been offered a project to take over, or a project team member, 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, early cost estimates, 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 to assess the extent of organizational change (and non-project staff time commitment) 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, staged as sequential or concurrent (concurrent is faster, but requires more talent and internal stakeholder time), and other execution considerations.
  • Preliminary business requirements, as prioritized by business unit managers, mapped to the problem or opportunity analysis, and 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, 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 or your project 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?