Project Management (Macro)

“Skate or die”(1) in its original usage advocated the skate boarding lifestyle as being synonymous with life itself. Here I co-opt it to zero in on the importance of scoping your project properly…put simply…scope or die!

Anyone who has spent time in projects whether they are technology, process improvement, quality control etc. should know that most failures can be attributed to a few usual suspects. These suspects include: inadequate executive support, lack of budget, lack of resources, time constraints but the most common culprit (IMO) is the lack of a proper scope. I’ve always asked project managers under my leadership to be able to provide an “elevator pitch” of their project (the ability to give a brief synopsis of the project in 2 minutes or less). After all, if you can’t explain your project in 2 minutes or less, you probably do not know what your project is.

If we are unable to articulate what it is we are trying to accomplish then we are unlikely to be be able to successfully deliver it. Furthermore we need to understand what scope truly is. Some fall into the trap of thinking that the scope is to turn on technology “x” or to achieve a certain number of widgets produced per hour or a reduction of adverse events by such and such an amount. Scope must be defined by the value, the benefit that it will bring to the organization/company. Scope, when defined by benefits, will be the guide by which the endeavour moves.

When a fork in the road appears the scope will help to determine whether the team goes right or left. Scope from a benefits perspective will ultimately determine the success or failure of the project.

Scenario

The Widget Company produces and sells widgets to business clients. They have been fortunate enough to be able to purchase and amalgamate two other companies with similar services into their own. The growth has come with some issues though. The other companies brought with them different invoicing systems and workflows. This is causing some customer service issues because invoices are in some cases not being created properly and in others they are not being created in a timely manner which is causing constraints on cashflow.

The company leadership wants to address the growing pains by introducing a new standard invoice computer system in all locations. They hire a project manager. The project manager schedules a meeting with the leadership team and asks them what the purpose of the project is. The leadership tells them that the purpose of the project is to implement technology “x”. So the project manager says: “So if I am able to turn on technology “x” in all locations you will consider this project a success?” To which the leadership team of The Widget Company answers in the affirmative.

• What if the system causes new delays in an unforeseen part of the process and actually delays the creation of invoices and compounds the cashflow issues?
• What if the increase in computer costs and technical support are greater than the efficiency in invoice creation?

Perhaps the scope (or purpose) of the project should have been to create the right invoice for the right customer at the right time. But is that enough?

• What does the company achieve if it is producing the right invoices for the right customer at the right time?
• Maybe it will decrease the amount of complaints that the company is receiving from unhappy customers?
• Maybe it will increase the amount of cashflow because they can reduce the backlog of account receivable?
• So perhaps the purpose of the project is to achieve an improved cash flow?

Hopefully as you are reading this you are beginning to see that the scope is the MOST IMPORTANT factor in the success of a project. There are any number of ways that the project purpose could be framed, being able to articulate the one closest to what the project is needed to achieve will go a long way increasing the chances of success.

Last but not least, once the scope (purpose) of the project has been identified the project manager needs to ensure that the scope is agreed to and authorized by the leadership (usually in the form of a formal document like a project charter that leadership physically signs off on). This will act as a kind of contract that the effort will be measured against.

(1) http://www.urbandictionary.com/define.php?term=skate%20or%20die

I had the opportunity to participate in a project management collaborative during the summer of 2012. The purpose of the collaborative was to conduct quality improvement sessions on the existing project methodology. The collaborative was conducted via small group break out sessions followed by a large group collaborative.

One of the main themes arising out of the sessions was around the subject of living versus dead documents. What makes a document living (changeable without strict change control) versus dead (changeable ONLY with strict change control)?

Living Documents
This was a topic of much discussion around the communication plan template in particular because our group had a formal sign off block on the template. The group questioned whether this was really useful or even appropriate since the communication plan is constantly being updated and executed as the project moves through the lifecycle. We all came to consensus that templates that are “living” should not have have formal approval (physical wet signature) but contain a structured accountability section (perhaps a RACI chart).

Dead Documents
So what about “dead” documents? The ones governed by strict change control which would include documents that authorize scope, budget and schedule such as: Project Charters, Project Plans, Statements of Work, Change Requests, Summary and Variance Reports etc.

Should stakeholders/sponsors be physically signing off on the document or should it simply be documented when they have been informed of or reviewed the document?

Our collaborative agreed that when we receive sign off on “dead” documents we will not go back and reopen them. Any changes to scope, budget and/or schedule will be reflected in the next project baseline document (project plan, statement of work, change request, final variance etc.).

When you put a signature on a “dead” project document it is in essence a contract between the project and the sponsors and then becomes subject to the same type of rigour that is put on a contract.

In project management we should always strive to only apply strict change control to documents that absolutely need it (due to contractual, audit or other criteria). To apply it to living documents as well would be a waste of time and money (sponsor meetings, presentations and the like) that could be used to much greater effect some where else in the project.