For those who are not in a position to follow complete Prince2, PMI or IPMA-certifications, here a quick and dirty introduction into the art of project management.

Introduction

In the basis, project management is just plain common sense. Whereas a journalist is only interested in the 5 W’s (What, When, Where, Why and hoW), every project needs the same. We just give each of them a separate name:

*Why (Project Brief)

*How (‘Waterfall’or ‘Scrum’)

*What (Work Breakdown Structure, sometimes with a Work Package Description)

*Who (Responsibilities, Stakeholders and Communication Lines)

*When (Planning)

And often a

*Stakeholder Analysis and Risk Log

Below I will describe all of these components.

Project brief (‘Why’)

Every project starts with an assignment. Some call it a Charter, some call it a Project Brief or a Mandate. Essentially they are all the same. In either case, it is a document from the sponsor(s) of the project indicating that she wants to spend x amount of money (and other resources like the time of project members) to obtain goal y (‘quality) in a set period of time (z). These 3 elements constitute the “devil’s triangle” and during the course of the project the project manager will continually have to choose between these competing restraints.

Usually, this document is written up by the project manager because she is more familiar with the format. In addition, it gives the sponsor a convenient way to verify that the message has come across. That in practice most ‘projects’ often are set up without such a document only indicates to which extent these endeavours deserve this prestigious title. Furthermore, the lack of this document is similar to the lack of an order: generally an indication of a lack of commitment of the sponsor, which means any strong project manager would severely consider whether there is any basis for cooperation at all.

Method-description (‘How’)

Every project has a certain structure in describing it’s goals. Roughly we can distinguish between 2 sorts of common structures: the traditional ‘waterfall’-method is often used in situations where a well-defined situation needs to be implemented, to ensure that the (often contractual) specifications are met. In such a case a Work Breakdown Structure is made based on the goals described in the Project Brief.

A more recently developed method is called ‘scrum’, where the sponsor in effect says: “Here is some money, some people and some time, and I want you to create something in that direction, see how far you get.” Even though this might be phrased somewhat provocative, in a dynamic IT-environment where surroundings might change overnight, this approach often works well and is very popular. Here, the goals are defined in user stories, which are realized in sprints of usually 2-4 weeks. These kinds of projects generally need to be managed by somebody who knows what she is doing, a ‘scrum master’. This blog is focusing on to those who do a traditional project.

Work Breakdown Structure (WBS, ‘What’)

If the goal of a project is to build a car, then this ultimate goal is divided up in intermediate goals to build it. Engine, Chassis, Wheels, Dashboard, Seats and Wheels could be the parts to be manufactured, followed by an Assembly. Each of these components then can be further divided up into substeps. Usually, 2 levels are sufficient, otherwise the project becomes too large to handle. The usual form to depict the WBS is the form that resembles an organization chart.

In addition to the components of content, there is at least one ‘Department’ called ‘Governance’ or ‘Project Management’ There all ‘process-related’ steps are maintained, like the setting up of a Project Team, the Kick-off Workshop and the production of the Status Reports.

In the ‘Scrum’-methodology, one works with ‘user stories’, which describe the functionalities a user would need or like. These user stories in effect are just another way of defining the ‘what’ of a Scrum-project.

Work Package Description (‘What’)

The term ‘quality’ in project management is used to describe the ‘acceptance criteria’ for the goal. Here it has nothing to do with good vs. bad quality, but more the philosophical ‘quality’ as opposed to quantity. For larger and/or more formal projects, the WBS usually is further detailed in a Work Package Description. This documents the exact delineation between various steps and the criteria to agree that a deadline has been met or not. In general it describes per part of the WBS

• What is in scope
• What is out of scope
• A general outline of the expected solution/outcome
• A way of measuring progress. That could be in hours spent on the topic, but also as e.g. 25% when the first draft has been produced, 50% when the client has approved the draft, 75% when the final copy has been delivered and 100% when the client has accepted the final copy. Such a set-up would prevent having to add another layer in the Work Breakdown Structure.

Responsibilities (‘Who’)

After all the necessary steps have been identified to reach the goal, we can assess all the parties involved in the change, a Stakeholder Inventory. These are not just the parties that contribute to the success of a project, but also those that need to be involved, and those that might pose a risk to the success of (the timely completion of’) the project.

To bring a project forward, the required skills for completing these steps. Generally, various roles are defined, like a mechanic for the engine and a foreman of a production line for the final assembly. Often, several people will need to cooperate on a task, and unclear responsibilities have stopped many a project in it’s tracks. Therefore, responsibilities need to be determined for each and every step.

Often, a so-called RACI-table is used for this purpose. There are many variations on this theme, but we will use here the most common one: for each task there is 1 person Responsible for doing it, 1 person Accountable if it does not get done, and multiple people can be Consulted, or spend their hours on it. Finally, the product needs to be provided to those that need to be Informed.

For most projects a Steering Committee is usually set up, in which both the sponsor, client/user and supplier are represented. The various project management-schools (Prince2, PMI and PMA are the best-known) differ notably on this topic. The Steering Committee is only one of the platforms in which parties are communicating, an overview of these parties constitutes the Communication Lines. Keep in mind that often these Communication Lines are just as important in the channels that they set up as in the establishment of Single Points Of Contact so that all not immediately required are sent to the appropriate party for information. When forgotten or not properly enforced a ´spaghetti knoodle-moodle´ will ensue.

Budget

When it is clear who will be doing which tasks, either as Responsible party or a Consulting one, these parties can estimate the hours and money required for each subpart. With the costs of hours the project budget can be established.

Every company will have it’s own standards of project controlling and reporting on the financial status, it is difficult to make generic statements on that.

Planning (‘When’)

And only then is it time to make a planning.

First of all, certain deliverables are dependent upon another: there is generally little use in hanging the doors in the coach body of a car if that coach body still has to be created. In addition, when it is clear that the Controller needs to establish a budget for a quote for which she needs 40 hours (=the budget), we need to check when she will be able to deliver those hours, since a long-overdue vacation of 3 weeks next to regular duties might make that impossible in the next month.

Crucial for a planning is that the roles identified earlier are now translated into individuals, and these individuals need to provide the planning. Usually, the project manager will do a first draft of the planning, after which the appropriate individuals then commit to it (or not). The project manager is responsible for ensuring there are sufficient buffers built-in to ensure the possibility, after which deadlines can be committed to the sponsor.

For a ‘Scrum-project, the planning is done in ‘sprints’ in which a certain number of resources (usually hours) are spent on the realization on certain user stories. Most sprints last anywhere from 2-4 weeks and at the end of the sprint certain functionality is delivered.

Stakeholder Analysis

Whenever the goal  and the way how to achieve it have been properly defined, one should assess the risks threatening the obtainment of that goal. The main risk (and opportunity) to assess is the immediate environment: who are all involved or affected by the project, and how (do they think that) they are affected?

Generally, every endeavour starts with an analysis of the customer: what does she really want? A Stakeholder analysis goes a little further than that: generally it starts with the assessment of a basic attitude towards the project of the relevant parties identified in the Stakeholder Inventory. One essential party to be included still is the ultimate client: what does she really want/need? Is time of the essence or is the control of cost more important? Furthermore, which departments within the (B2B) client play a role? Are some of them even hostile to the success of this project because it goes against their own strategic interests? Or does the Workers’ Council pose a risk if they are kept out of the loop? Based on such considerations, special actions, newsletters, information sessions etc. might be undertaken to keep these parties on board or reduce their resistance.

The only way to make this document of value is to keep the assessments absolutely confidential: nobody would like to read back somewhere that he expected his own Controlling Department to try and torpedo a project!

Risk log

In addition to risks coming from stakeholders, there might be additional risks to consider, e.g. the outburst of a strike at a supplier might delay the delivery of components, which in turn could hold up construction significantly.. After description of the risk, it needs to be assessed, whereby both the probability of occurrence (‘P’) and the impact (Í’) often are assesed on a numerical scale, after which their (multiplication)product allows for a ranking of the severity of the risk.

Based on this ranking, certain precautions can then be taken to either prevent the situation from happening (e.g. by getting a second supplier), mitigate the effect (by creating an intermediate storage of these parts), or the acceptance of a risk as being unfeasible to prepare for (e.g. to prepare for the risk of nuclear war).

In the course of a project, additional risks will be entered into to the original risk log, e.g. that a supplier will not be able to deliver in time. One risk that always seems to pop up is the workload of project team members: somehow always the same people are asked to do them, next to their normal activities, of course.

Reporting & Control

In the Work Breakdown Structure, several actions have been identified which need to be done. Still, along the way, several items may come up that one would not necessarily put in a project plan. These items are usually tracked in the action item list or ‘Open Point List’.

Finally, all involved and especially the Steering Committee will want to be updated on progress, for which a Status Report is produced periodically. That such a Status Report is based on the developments of the items above as is obvious.

The complete library of all these documents often is called the Project HandBook. When that is written, the project manager is not done, the project only has started. On that note, remember that I believe it was Dwight Eisenhower who already said: “There is no plan that survives contact with reality”

(Originally posted on April 29, 2015) Edit July 19: added Stakeholder Inventory + Communication Lines