Project Strategies and the Importance of Being Able to Think Critically

Posted by Rich Crowley in Project Management, strategy

In commercial and public organizations, it is typically the responsibility of senior management to set and communicate the high level direction of the organization.  This direction should be a succinct summary of what the organization is all about and is often equated to being the vision and/or purpose of the company.  I believe this directional element of an organization should answer the question of why the organization exists and what it produces.  Apple Computer’s vision / purpose could perhaps be summarized as “building insanely great products”.

Once direction has been established, there needs to be a means of achieving that vision / purpose.   This is where the element of strategy comes in.  A strategy should answer the question of how the organization will achieve its vision / purpose.  A strategy can be used to provide such direction to a large group (ie. a state, an organization) or a much smaller entity such as a business unit or team.  (A strategy can even be created for something that applies to a single individual).  It can be very simple and brief or quite detailed.  Achieving an organization’s vision / purpose often requires a mix of operational and project initiatives.

Projects are by definition unique chunks of work.   (If a unit of work is a non-unique, repeatable collections of tasks, it is typically considered operational in nature).   When something unique needs doing, it needs to be determined how best to accomplish the work, since there is often no precedent to draw on.  The purpose / vision that drives a project is typically provided by the sponsor.

I believe the strategy or strategies required for achieving a project’s purpose are, along with solid communication, the most important accountability of the Project Manager.   I believe such strategies require the PM to be able to think critically in the absence of guides such as templates and frameworks.  Such artifacts are wonderful for helping a strategy get documented cleanly and according to an organization’s project governance model once the project has been thought through.  However, too often I see strategies produced that are nothing more than boilerplate documents filled in with virtually no fresh thinking that addresses the unique elements of the project.  It is ironic that standardized templates are the norm for documenting how to do something that by definition has been agreed to as unique.

It should be noted that while I view the PM as accountable for the various strategies a project requires, they are rarely responsible for creating these (with the exception of the overall, summarized project strategy).  Instead, the PM needs to ensure that the various domain experts create these as required.   It is also the PM’s role to challenge the thinking of these domain experts in the strategies they produce (which is why it is beneficial to have a PM that has either technical or domain expertise, or both).

In projects that use a Waterfall methodology, there are a myriad of strategies that could be created.  A large project may have a full-blown strategy of it’s own.  I sometimes refer to this as the “Project Approach”.    Often, the project charter is the artifact where the overall project strategy gets documented.  However, in organizations where the charter is a very early, light deliverable, sometimes this is not the appropriate place because not enough is yet known to articulate an overall strategy.  Regardless, I believe this overall strategy should be written down and is the PM’s responsibility with oversight provided by the sponsor or key stakeholder proxies.

As the project is broken down into further details, it is common for lower level strategies to be needed.  For example, what is the strategy / approach for collecting requirements?  Too often, analyst resources simply get assigned and it is left to them to go about gathering requirements in whatever way they have used in the past.   The folly here is that if the analysts have traditionally used an interviewing technique and the given project is one where key stakeholders are in remote locations or otherwise unavailable, the requirements gathering process will quickly break down.   Someone needs to assess up front what resources, skills and tools are available for the job and then match those against the nature of the project to see if there is a fit.  If not, perhaps some new techniques need to be considered or some resource gaps exist.

Another example is the design / development approach.   It’s fine to hand over the requirements to technical staff and say go but there are so many questions to consider to optimize the design / dev phase.   Like the requirements discussion above, one needs to assess if the design / dev resources have the skills and tools?  Is there new technology involved?  If so, is training required or should the existing developers be complemented with external experts?   How does one estimate with new technology that is less understood?  In a world that has so many interconnections between organization to get projects done (ie. vendors, suppliers, consultants, etc.), more than ever there is a need to assess how best to equip people in a way that best supports collaboration.   Should external collaboration tools be used (ie. BaseCamp for project management, Jira for bug tracking etc.).  These are all elements that should be considered as part of how best to build what needs building, before the building gets too far along.

Testing is another area that needs a lot of thought as to the optimal approach for ensuring the quality of the project’s outcome.   Templates are significantly over-used for creating test artifacts in my experience.   A solid test strategy is less about testing than it is about understanding how to take the inputs and outputs from other aspects of the project and ensure the ultimate project outcome is achieved.   Do we have data that will even allow testing?  If not, is there a way to manufacture it?  If not, is there a way to find some proxy for it in production? Are there specs against which to test?  If not, do we need to create them?  Is automation required?   Can the project absorb the cost associated with developing an automation regime, which are very significant both for intial setup and ongoing maintenance.

Rollout /implementation is another often overlooked element that requires a strategic perspective.   Some common approaches are to phase the project into production, a cold-turkey / turnkey approach, running parallel, etc.  In all cases, there are usually attributes of a given project that will allow such options to be critically assessed as a good fit or not.

The bottom line here is that project strategies require thinking in the absence of best practices first and then followed by whatever work is necessary to fit the defined strategy into the organization’s project governance model.