Project Management in Practice

Beyond the alphabet soup of PRINCE2, MSP, MoP, PMBOK, ITIL, Agile

Category Archives: Stakeholder

How do I estimate based on risk?

Risk Management - Image from bigthink

Risk Management – Image from bigthink

I have previously contemplated the challenges of keeping to scope and budget and keeping customers happy. If a customer adds new requirements on to a project, it is an easy discussion to have around additional time and cost, or a reduction in scope elsewhere. Grey areas in scope aside, you can show a definite impact on the project because of an omission that needs to be rectified. Where I see challenges are in trying to prevent slow bleeds.

One approach is to state assumptions that all dependencies will be met and manage exceptions by change requests. From experience I find that is a hard way to manage. How long does it take to do a task? The answer is always depends. You may be doing a task very similar to that you have done elsewhere. However, you cannot assume it will take the same amount of effort or elapsed time. The environment where you are deploying, number of other suppliers involved and in-house expertise of your customer all play significant roles. Experience tells us that we must take into account these factors as risks when we estimate project cost and duration.

My area of expertise is in delivery of IT projects. However, I believe the principle is the same in all fields of work. In an IT context, even in simplest projects you will have a customer taking on the task of solving a business problem through a project. The supplier will be engaged to deliver the project to a scope. Usually interactions are required with subject matter experts in the business, the IT service provider for the customer (could be in-house or another supplier), possibly procurement … to note a few. There are risks that we must associate with each of the players and estimate the project accordingly. While it is difficult to create a good risk profile for a new customer, we should be able to build a reasonable picture for customers we deal with regularly.

Think of a scenario where one of the other suppliers delay delivering a component that is a pre-requisite for your delivery. It may only have been delivered a day or two late. However, you have created an optimum resourcing based on something being delivered on the agreed date. In reality, you cannot re-assign those resources unless you have significant notice of the delay. Even if you know well ahead of time, in many occasions it is impractical to re-allocate those resources to another project, due to the short available window. By the time they are up to speed with the other project, it will be time for them to start working on the original assignment. Effectively the supplier through no fault of their own ends up absorbing the cost.

Sometimes the lost time is less than days, maybe a few hours every week due to lax turnarounds to required information or pre-requisite delivery. However, at the end of a project it does end up being a significant impact. You cannot really go back with a change request every time something is delayed by an hour. This will give a new meaning to death by change request. And you can be guaranteed a breakdown in communication with your customer. How so do we then ensure projects do not suffer this fate?

PRINCE2 Risk Probability Impact Grid

PRINCE2 Risk Probability Impact Grid

The only way around this dilemma is to expect some level of these risks materialising. PRINCE2 suggests using a probability impact grid to evaluate risks. While PRINCE2 is predominantly useful for the end customer to run the project, there is no reason the suppliers cannot use similar techniques to analyse risk. It is worth analysing what your particular scale for impact or probability is to get a good feel for impact. When you are constructing your estimates and plans, have these built in.

The key message here is to initiate a change request only when the risk that you have tolerance for in your plan is exceeded. Many IT projects fail to take this into account and bleed. One can legitimately ask why doing a PERT estimate should not take these risks into account for the pessimistic scenario. The key to remember on that is when you get your technical staff to estimate the pessimistic scenario, they are taking into account pessimism from a technical point of view, whether that be an unknown pattern of software development, familiarising with new API etc. They are not taking into account human or communication risks.

In my observation, construction projects are better at taking risk budget into account than IT ones. This is possibly because a half finished construction project is an obvious reminder of a failed project. Failure of an IT project is usually a less visible eye sore. That has probably made those in IT projects lazier than we should be.

Hitler implements SAP

The resourcing conundrum

In almost every organisation I have worked, I have seen the dilemma of resourcing in an optimum manner. Every services organisation will try to get maximum utilisation of their staff. This is how you make good money. As Murphy would have it, there is never the perfect synergy. Either you have too much work and not enough people, or the exact opposite – too many people sitting around twiddling thumbs.

Sometimes you wish work comes in a less lumpy fashion. However, there are practicalities of procurement that get in the way. Where work is of less immediate urgency, you can try and get your clients to accept delivery at a time suitable to you. However, your clients too have certain timeline. And then there are times before the end of the financial year when people have money to spend, but your capacity take on the work may be compromised, as there is too much work.

In trying to make your pipeline less lumpy there is the chance of your customers becoming dissatisfied with you and going to the competition. So that is a delicate balance to tread. One option many organisations utilise is using contractors. My experience with contractors is mixed. I have worked with some excellent ones and some that have been on the lookout for the next contract or worse intentionally making work for themselves at the expense of the project.

Alliances and business partners could come in quite handy in these scenarios. In essence, these are the same as contractors, but an organisation rather than individuals. While you may encounter some of the same risks, you are more likely to get better quality work out of them. It is in the interest of that organisation to provide quality output. The risk comes more by introducing potential competition to your customers. What is there to stop them going to them for the next project?

If you have read this far expecting concrete suggestions, I will have to disappoint you. It will always be a judgement call based on the size of the project, the customer and their likely reaction, threat of competitors and availability of contract organisations or individual contractors. In some cases you may have to go for a combination of these or compromise an existing project to get through. I am risk averse in deliveries and prefer control of resources.

I generally prefer partnerships with organisations over individuals and mitigating risk by engaging with an organisation with different strengths to avoid future direct competition. What approaches has worked for you? Have I not considered options that you have successfully used?

Be careful not to try and squeeze every last bit of capacity out of your team. Leave some space for unstructured experimentation and self learning to ensure they keep ahead of competition. In reality you will get many fold more productivity out of them than the time they use for this.

Image Credit: LightningArt.Com

Working with Project Sponsors

I went to the Wellington PRINCE2 User Group meeting this week. The topic of the meeting was working with project sponsors. The user group has a format where it invites three speakers, each speaking for seven minutes and no PowerPoint is allowed. At the end of the talks, there is the opportunity for Q&A, group discussions and networking. The three speakers were all of exceptional quality – Philippa Jones, Don Robertson and Dr Judith Johnston.

It was an interesting discussion led by three very experienced project sponsors, some of who also had experience in project management. The key point that came out consistently during the night is that the Sponsor and Project Manager need to work in partnership to achieve successful outcomes. In a PRINCE2 project, the sponsor is someone from within the business and is called Executive. Project sponsors are usually individuals with significant responsibilities and consequently limited availability. Yet, they are ultimately responsible for the project and therefore need to be consulted with effectively to ensure the project is likely to achieve the outcomes sought.

This requires effective planning and delegation of authority. The Project Manager is responsible for managing day to day activities of the project. The sponsor is not there to help on day to day matters. The sponsor is there to advise on direction of the project, help with organizational knowledge. One effective use of your sponsor can be to handle resource commitments from teams where the Project Manager is not a line manager. However, that should not delve into the management of individuals in the team. Levels of authority and tolerance should be set out in the Project Charter (PID in PRINCE2).

Preparation is key in establishing working relationships with project sponsors. Providing the status report just before the meeting does not augur for a productive Project Board meeting. At the beginning of the project the Sponsor and Project Manager need to establish the outline of the reporting structure. Reporting is likely to be different based on what the project is trying to achieve and what are considered the Key Performance Indicators. Ground rules need to be set out regarding communication procedures – when the reports should be sent, in what format, how risks and issues should be reported and escalation methods.

Trust is the basis for this working relationship. Communication needs to be open and transparent between the Sponsor and Project Manager. If there are issues in the project, do not hide from the sponsor – report Red as Red. If the issues are with Senior User or Senior Supplier groups then approach the Sponsor directly to appraise them of the situation. Bringing something to light too late in the piece will take away the Sponsor’s ability to influence outcomes. Uncertainty is usually what causes status reports to be rosier than what they should be. The Project Manager must agree with the Sponsor how uncertainty should be reported. Uncertainty, especially in the early stages of the project, is quite common.

The Sponsor’s exposure of the project is usually not on a continuous basis – usually monthly in large programmes. If everything goes according to plan, then this may be sufficient. However, it is a good practice to have an informal meeting with your sponsor in between status meetings. This ensures your sponsor is kept abreast of developments. Any issues from the project should not get through to the sponsor from other channels than the Project Manager. This will only serve to undermine the trust between the two. The Project Manager must also ensure what is submitted in written status reports correlate to what is being communicated informally in between the formal reports.

Involving the Sponsor is usually associated with something going wrong in the project. This does not have to be the only reason to involve your Sponsor with the project team. One of the speakers related how she looked forward to celebration of achievements in her projects and the ability to say well done. Although it was not necessarily the key message of the evening, it is one that stuck with me.

Project Manager runs the project on behalf of the Sponsor. The role of the Project Manager is to manage the project within the tolerances afforded to him. The role of the Sponsor is to enable that environment to flourish, so the desired outcome is achieved.

Image Credit: GlenKnight.Com

%d bloggers like this: