It doesn’t seem that hard to define a project’s approach. It’s just a description of the project strategies for achieving the project objectives. Simply stated it’s the path the project team will take to get to the desired end result. Simple as it may be it still drives many project managers nuts, causing them to stare at a blank page, unable to articulate anything of value.
Three types of project managers struggle with defining their project’s approach:
Type 1: those who have always worked on projects of the kind.
Type 2: those who have worked on similar projects but the conditions of the current project are not at all the same.
Type 3: those who have never taken on a project of the kind, nor has their organization.
Type 1
Most industries have standard development approaches. Software development has the classic waterfall approach with: requirements, design, development, test, and implement. Drug development with: discovery and research, development, regulatory review, and approval. Construction with: concept, design, drawings, construction, and commission. These standard approaches are not just detailed at the higher levels they are standardized deep into each phase.
As a result, most projects under normal conditions follow these standard approaches. It’s no wonder project managers struggle documenting their project’s approach as anything other than “do what we always do.” This should be an acceptable phrase, one that can be used often. Let’s stop thinking it needs to be anything other than that.
Type 2
When the project’s conditions are anything other than normal the project approach needs to be something other than the status quo. Here, project managers need to clearly identify what is different. Does the project need to be completed in an extremely shorter than usual time frame? Are the details of the end product extremely vague and not because someone has not thought about it hard or long enough? Are there large risks to successfully delivering the end product?
Once the project manager knows the reason(s) for the variable conditions they now need to identify the flexibility they have with the end deliverable. Does it have to be delivered in one fell swoop or can it be developed through multiple “less than perfect” versions? Examples of the former are putting on a conference, constructing a building, and building nuclear reactor control systems. Examples of the later are creating web sites, building consumer products, and developing certain software systems.
Another element to define in this situation is how important this project is to the organization. Does the organization’s existence rely on the project’s success? Will it be significantly hurt if the project is not completed successfully? Basically, the project manager needs to know how creative they can be in coming up with a viable approach. Budgets and organizational resources are typically the main constraints to viable approaches.
With all these questions now answered the project manager can take their existing standard approach and decide how to change it to meet the challenges. One of the first areas to look at is how the end deliverable will be developed. If the project needs to be completed in a much shorter time frame than usual, a project manager may choose to initiate development phases that would normally be completed in series, in parallel. The contractor responsible for building the aquarium to save “Free Willy” movie’s star and orca used this approach. The orca was going to die if he was not moved to a new facility by a specific time. The standard time for developing the facility had to be significantly reduced to meet the needed time frame.
If there are big technical risks, than using an iterative development scheme will eradicate the risks early in the project and allow for a more certain end finish or quick project shut down to save time for plan B. Iterative development is also good for helping end users identify what they ultimately want by giving them a version of the product that grows in functionality over time. This approach is how Linux, the open source operating system, came to fruition.
If a project manager has vast budget and resources availability then experts and additional personnel can be acquired to ensure a successful completion. Y2K was a great example of this. Companies had to get software converted by the end of 1999 and they pulled out all the stops to make sure it happened.
Type 3
Now let’s address the project manager struggling to develop the project approach because they have just been given responsibility for a project of the kind they have never worked on before, nor has anyone else in their organization. Obviously there is a lack of knowledge and experience, but that is only the crux of the situation. It is not that the project manager isn’t creative enough; they just don’t know what they don’t know and also don’t know where to begin.
Thankfully in today’s world we have tools that give us access to an enormously broad spectrum of information. Via search engines and bulletin boards one can find out how others approached similar projects. Plus with social networks, both personal and professional, help is just a post away. However, there is no silver bullet if a project manager finds themself in this situation. They have to work hard and cast their net wide to get the information and experience they are looking for.
Hopefully with the guidance given here you will know when to relax and not stress out about being strategically creative, have a roadmap for creating a strategy that meets your radical project conditions, and know when to become a sponge and soak up as much knowledge and other people’s experience as you can to meet your new project’s challenges. So, don’t sweat it; it’s really the strategy that will guide you to success.