Managing Project Risks in Four Simple Steps

What are project risks, and why do we manage them? In simple terms, a project risk is one answer to the question, “What could go wrong?” If you can anticipate potential problems that would impact your project’s quality, budget or schedule, taking steps to prevent them makes a lot of sense. Additionally, having a backup plan in place amplifies your ability to recover should one of those risks become real. Thus, risk planning greatly increases your overall potential to lead a successful project.

“No battle plan survives contact with the enemy.” – General Colin Powell

I say it a little less dramatically: “If you don’t have a Plan B, you don’t have a plan.” (Yes, you may quote me…) Let’s walk through the four easy steps to building a risk management plan. These steps are based on straightforward questions, which in my experience add a level of clarity that is sometimes missing.

1. List potential risks. To build this list, simply ask “What could go wrong?” or “What if…?” As you brainstorm the list with your team, assign a probability for each. You don’t need to get fancy or over-think it. Just give it your gut feel on the first pass. You can always adjust it later. Make it easy. Is it likely, or unlikely? Is the chance of this occurring high, medium, low? That is plenty of detail for this approach.

 

2. Establish a mitigation plan for each risk. For each item on your list, ask “How do you prevent that from happening or at least lessen its likelihood?” The answer to this question is your risk mitigation plan for that event. Reducing the likelihood of a detrimental event occurring is the ideal risk management strategy. Prevention is better than remedy every time.

 

3. Develop a Plan B. Ask yourself, “If that event does occur, what is Plan B?” For the high probability risks, you will want to have a Plan C too. Document the backup plan! Now take a quick look at the big picture. How likely is it that Plans A, B (and C) would all fail? That should be very unlikely, which means you have reduced the risk of failure!

4. Assign a risk monitor for each item. “Who would be the first to know?” That is your responsible person. That person is to monitor and report to the project manager immediately should a risk occur (or even be anticipated). If something goes awry, the risk monitor is your first line of defense. This does not mean everyone else can abdicate responsibility for monitoring risks; the whole team is responsible, especially if something happens that is (dare we say) unforeseen.

 

So how do you document steps 1 through 4? There are numerous templates and tools available, so search around and choose one that seems a good fit for you and your organization. At a minimum, the risk log should include the following categories:

Description of risk

Probability

Mitigation plan

Plan B (the backup plan)

Assigned risk monitor

Additional fields that may be beneficial:

Risk identifier (just a sequential numbering system will work. I use R-1, R-2, R-3, etc.)

Current status (active or inactive)

I’d like to express one more thought concerning risks versus issues. In practice, risks and issues can get muddled in the minds of team members. This is especially true in organizations with less savvy project team members. For this reason, I include a simple distinction within the narrative portion of my project plans. Simply defined, a risk has not yet occurred, but an issue is happening right now. Then I elaborate a bit further just to confuse them a little (I’m kidding): So, if a risk comes to pass, it can be considered an issue, but an issue does not have to start as a risk–it might be unforeseen.

 

So there you have it, four simple steps and the elements of a log to document your risks. Use these steps as outlined to reap the benefits of this oft-neglected area of project management. Here is what you get for investing the time to develop a predetermined set of risk management actions:

 

increased likelihood of successful project completion

saved time that would otherwise be used figuring out what to do when something goes wrong

documented plans and strategies for future reference

increased confidence in the overall project plan

increased control of the project

And as if all these benefits were not enough, you will surely look like a hero if something does go wrong and you have the backup plan all lined up and ready to deploy.

Does knowledge in the delivery area allow for bad habits?

I want to explorer the topic of the experienced PM. In the industry we are seeing that companies are advertising for PM’s with 5+ or 10+ years experience in there field, whether that be IT, Telco, Managed service or TnT. This has left me thinking does it really matter if you have experience in the field or is there a better question to be asking?

When i reflect n my experiences through the years there a few PM’s that i remember distinctly as the people who cement this point of view for me. In 2003 i started with a business that specialised in Project Management Consulting and i was closely involved with the MD at that time. whilst very financially astute he was extremely good with people.

With these skill sets i saw him get brought on board to various project types and size and execute a clear and welcome leadership to the direction of the project. He did this successfully from Major branch upgrades in the banking sector through to the telecommunication roll-outs of 3g networks to major event (Sydney Olympics).

How could one individual be able to get the same or better outcomes for industries that he had no experience in? So in one of the many session i got with him i asked and he proceed with,”If you understand your Scope, your Risks, your Financials and your time frames it is then the give ownership of elements of that picture to the right person and support them in every way you can.”

So many years after that i have carefully watched the PM’s that i have worked with, this was further cemented in 2009 when i was on a large transformation program and the company was struggling to deliver and  we found that the person that had that scope of work was whilst very experienced in the area and had many years in project management, made desicsion in isolation, he did not care for process or people all that mattered to him was the people around him said “yes”. No rocking if the boat and no different point of view if you did you were seen as to hindering him. Now after many, many,many months of this and high engagement of my business to the with the executive of the company they finally removed him a brought in someone else , but by then it was already to far of the rails.

So i have found that actually that is right that specialised knowledge in the delivery area allow for bad habits, if you understand and clarify what ever you are delivering and you enable and support the team around you, you don’t need experience in that specialised area.

When Estimates Go Wrong!!!!!

“What’s that ticking sound coming from the engine of the car? Must be a loose valve. I’ll take the car to the mechanic for a valve adjustment…”

At the garage, they look up the flat-rate time estimate for a valve adjustment. It’s easier to estimate when you’ve measured the actual time from lots of competent people doing very similar work. They multiply that time estimate by their labor rates, add in some extra for gaskets, shop supplies and such, and give me a cost estimate. “It should be ready by 5:00.”

I go on my way, knowing I can pick up my car in the evening and how much it’s going to cost me. All is right with the world. But in the late morning, I get a call from the mechanic. “Your car doesn’t need a simple adjustment. The pushrod is bent. The reason it got bent is that the threads holding the rocker arm assembly are stripped out of the cylinder head. We’re going to need to keep your car another day, and the cost will be about triple the original estimate.”

What do I do with this information? I could berate the mechanic for giving me a bad estimate. I could insist that he only charge the originally estimated amount. I could tell him to work through the night so that I can pick up my car first thing in the morning.

I suspect that you don’t do any of those things. I don’t, partly because I don’t think it will get me what I want. Instead, it’s likely to damage my relationship with the mechanic, and get me less of what I want.

Custom software development is notoriously difficult to estimate. We start with vague ideas of what we want, expecting to fill in the details later. We’re usually doing something a little different than what we’ve done before, or completely different. If it weren’t different, we wouldn’t be doing it at all. Software development is orders of magnitude more complex than fixing a mechanical system. It’s fractal, whereby whenever we go into more detail, we also discover more complexities. It’s a very creative endeavour, requiring intelligent imagination.

We compound the difficulties by not keeping records that allow us to compare this work with previous work. We change the makeup of teams, so that even when we can compare the work, we can’t compare the workers. We add bureaucracy and technical constraints that may not be obvious when making the estimates. We change the circumstances after the estimates are made. We often expect other work to be done in the same time as the estimated work, without accounting for the loss of time and efficiency due to multi-tasking.

In spite of all these difficulties, I’ve observed managers berate developers for bad estimates, insist that they finish the work on the previously estimated date, and demand they work overtime to do so at their own cost. This article is not, however, about all the costly damage done by such reactions. Instead, let’s look at how we can act more productively.

When estimates and actuals don’t match, trust the actuals. Should you adjust the estimates to match? If you do this, then you can adjust the plan accordingly. How early can you test the correlation between the estimates in your plan and the actual rate of progress? When work is performed in large blocks and integrated at the end, it’s far too late for effective re-planning when the difference is noticed. How can you validate your plan earlier?

Working in small increments and continuously integrating can help, but you also need to know that those small increments are actually done. Using estimates of “the database layer is 90% done” won’t help, as you’re back to depending on unverifiable estimates. Rather than creating small increments based on the building blocks of your project, try using small increments of functionality. These functional slices will touch numerous building blocks, but can be tested unambiguously as to whether or not they work as desired.

After re-planning based on the reality you observe, you can attend to fitting that plan into your constraints. If progress is too slow to fit everything you want into your budgeted time or cost, consider trimming the scope of the work. This can be done by eliminating features, or by slimming features down into easier–though less capable–versions. You may have to make some difficult decisions about priority.

Observe where your delays and bottlenecks are. What makes the actual speed as slow as it is? If it seems that things “should be faster”, then it’s possible they would be–except for an accumulation of difficulties that impede progress. Perhaps there are some quick wins in out-dated procedures that can be eliminated and speed up progress. Perhaps the internal quality of the code has been ignored to the point that everything is hard to change. It will take time to improve that quality, but it will eventually pay off in faster development speeds.

Make adjusting estimates easy. Estimate in artificial units, and roughly correlate the artificial units to the ones you need to examine. People use story count, story points, t-shirt sizes, animals and other analog for estimation sizes. Try to be consistent, but be aware that estimation will vary over time. An advantage of artificial units is that you don’t have to go back and re-estimate when the apparent speed changes. If you were accomplishing 38 stories per month, and now you’re accomplishing 46, you don’t have to worry so much where that 8-story-per-month improvement originated. Merely project using the newer figure, and see what that does to your plan.

Don’t expect estimates to be precise. If you need them to be precise, you’re trying to plan too close to the edge of failure. Don’t rely on optimistic numbers. Also think about what a downturn would mean. Don’t validate your estimates with reality only once. Continue to re-check throughout your project. Work in priority order so that you can re-plan frequently to the end, but still deliver the highest priority functionality. And if you cannot prune the scope to fit and still achieve the project’s value, then you’re likely to be working on the wrong project.

As Tom DeMarco said, “Strict control is something that matters a lot on relatively useless projects and much less on useful projects.” [“Software Engineering: An Idea Whose Time Has Come and Gone?”, July/August 2009 IEEE Software, pp 96, 95] Projects with a high return on investment can survive a few inaccuracies in estimation. Projects that need precise estimates likely won’t return their investment.

Recovery? on the back of a coaster? Never going to work.

I want to share my experience of the PPM Community and how i have seen the teams on how they take on the re-baselining and recovery process with in flight projects.

Usually it is started at a point that the delivery project team is starting to miss major deliverables  and the client just wants to be able to get a date that they can commit to all their internal parties with out having to go back again. This is shortly followed by a deadline of 2 weeks to re-plan the whole project , dependencies, resource plan and activities and come back to the them with the date they could meet meet.

Because this decision is usually made at a steering committee and it takes 2 days to filter down to the PM’s that this will need to be executed by.  Once the PM hear the pressure is off they are usually mid flight in a process and puts this opportunity to a low priority on top of all the other requests made on them by all of there stakeholders.

So now a week later the PM is tapped on the shoulder and by the Program Manager asking how the re-planning is going usually meet with a very blank look. Followed by a conversation about what is a higher priority getting the activity that he is currently working on or this re-planning exercise?

Then in the new week the PM starts to get his team together and promptly realises that it cant be done in their isolated stream. The PM proceeds to get all parties in the room to ensure that this plan contains all the know work they need to do to get to a point  the client will be happy with.

The planning is complete in a day on a white board and the all the problem that the PM has been facing over the duration of the project so far are not factored in and a miracle date is produced and promptly communicated to the client……….. very shortly followed by some time being lost in the communication between the executives and the client.

Why do PM’s who understand the project in detail

1. Not do proper planning using a CPM tool?
2. If under pressure request for specialist support to ensure a plan contains risk, assumptions and required commitment?
3. Never add any contingency in the plan based on what has happened so far?
4. Never ensure that the contract requirements a retested against the new plan?
5. Never contain the outstanding work?
6. always have the highest technical risk?

I know all of these points above will not return a palatable result but this gives you and your client a full understanding of all of the risk that they are asking you to take and what impact that it may have on their business.

5 Must dos for recovering failed projects!!!!

So what are some of the things that need to happen before you can achieve any improvement?

ACKNOWLEDGE THE FAILINGS

When doctors treat patients with substance abuse, the first thing they try to instil on patients is the acknowledgement that a problem exists. The environment around failed IT projects is exactly the same. It lurches from one problem to another while trying to apply band aids to keep things going. Until parties are willing to admit problems exist, there is no hope for a resolution. If you keep doing the same things there is no chance of the result being any different than what it is today. It is very likely that some within the project saw the train wreck coming and may have voiced it. Seek those out to understand what went wrong.

DIVORCE EMOTIONAL INVESTMENTS

One of the basic practices of IT is that software developers do not test their own code. It is not because they are not capable. In fact, they should be more capable than anyone else. However, as human beings we are predisposed to not finding holes in our creation. Same is true for the management of the project. The current status is a reflection of many decisions taken through the course of it. Many in the management will feel the decisions were correct at the time with the information they had at hand. You need to remove the management decision makers from both the supplier and customer to ensure progress. Leaving them intact will risk required changes not happening. If the changes do happen, it risks those people losing their authority as they have been “proven” wrong in hindsight.

AIM FOR SMALL WINS

In a major failure it may sound counter intuitive to look for small wins, as the problem is a sizeable one. Most adults are reasonably sensible and not easily taken in by bulls**t. They are well aware that a major failure and is not going to be resolved quickly. What you need to achieve at all costs is some confidence among your user base that improvements are underway and they can see a light at the end of the tunnel. Bigger your ambition is, more balls are in the air and higher the chance of it all coming crashing down because of weak foundations. Identify how you are looking to improve, set target of small improvements often and communicate honestly.

THROWING MORE RESOURCES IS NOT ALWAYS THE ANSWER

As Fred Brooks Jr has pointed out, the most reliable software is written by one or two man bands. The need for quicker output requires many more developers and as a result introduces complexities several folds. One of the major reasons projects fail is because communication is poor. Having large teams working on it is therefore more risky than the original projects. It is a common tendency in projects to throw more resources at a problem. That is just about the worst things you can do in a failed project. With smaller wins go for smaller teams.

BE PREPARED TO ABANDON THE PROJECT

For all the best will in the world sometimes you will not be able to retrieve failed projects. Cost of retrieval may be higher than doing another project from scratch. It also may not give you the benefits you were after based on the additional cost. You may find there is more political will to spend in trying to fix something than re-doing it correctly or abandoning it. Be careful to be seduced by that. Supermarket chains, farms and IT industry contains a lot of similar requirements with a considerable part time contract staff alongside permanent staff with various levels of skills and entitlements. A fully functional system that does 90% of the requirements may be better than an error prone system designed to deliver all of the requirements.

Great Article – To all in the PPM World a must read Article that shows where the PPM world is heading

PPM Article

Top 10 Questions for EVM Readiness

I completed an assessment on earned value management readiness based on 40 critical success factors found in successful earned value management implementations. The project managers in the assessment provided feedback on the assessment statements and their usefulness in determining earned value readiness in their own organizations. The assessment statements were ranked according to their usefulness in determining EVM readiness.

The top 10 in order of priority are:

1. The PM staff demonstrates the ability to develop project schedules and track against a baselined schedule as evidenced by project schedule baseline and actual variances, milestone counts and late task counts.

This assessment statement isn’t a surprise, as having a strong competency on schedule development and schedule management is critical for an EVM implementation. A poorly defined project schedule will still be a poorly defined schedule even if you try to apply earned value metrics against it. By focusing on the core competency of schedule development and scheduling tracking, project managers are establishing a critical success factor for EVM.

2. The management supports EVM and provides a top-down direction on its use and application to project management as evidenced in management communications and project portfolio reviews.

In assessing and talking about organization change management and project sponsorship, I often hear the overused words “top-down management support”. I’m sure you’ve heard it so many times in your project management classes that you may have glazed over this assessment statement. We’ve all heard it and acknowledge it yet can reluctantly admit to have vainly tried to implement project best practices without it. With successful EVM implementations, you need the organization’s support and its inclusion in portfolio reviews and management communications. If the organization isn’t behind your effort, its impact will be significantly minimized.

3. Resources (personnel, tools, funding) are committed to implement the EVM initiative as evidenced in the department budget.

If EVM is going to be successful in an organization, it cannot be left as a bottom-up effort from the resource pool of project managers. It needs to be a funded effort with coaches, scheduling tools and training to make EVM successful. One solution is to have the enterprise project management office fund EVM training and coaching at the corporate level.

4. The organization’s project management methodology uses objective status metrics in project status reporting with such metrics as milestone counts, schedule variances, cost variances and deliverable tracking.

Earned value management is a quantitative method to report project progress. If the organization is not already incorporating milestone counts, deliverable reporting or some form of objective reporting, EVM might be too advanced of a concept. Start out with simple task or milestone tracking and introduce SPI as organizations understand the value in objective performance reporting.

5. The staff has the necessary skills and resources to implement EVM as evidenced by training history, staff confidence or defined roles and responsibilities documents.

Similar to assessment statement No. 3, the skills and resources need to be in place to support an EVM implementation. If the organization doesn’t have the skills in-house, hiring external consultants to implement the methodology, provide coaching and knowledge transfer will help develop the skills within the organization.

6. The project has well defined scope as evidenced by a scope document, requirements document (or specification) and a work breakdown structure.

If the project isn’t well defined in a project schedule with a time-phased budget, it becomes impossible to track the project with EVM. A well-defined WBS, scope document or requirements specification needs to be available to support EVM. If the organization doesn’t have one of these fundamental project management artifacts, the organization should focus on creating them before jumping to an EVM approach.

7. The project organization understands earned value management concepts as evidenced by PMP certification, existence of an EVM process guide or use of EVM terminology.

Before EVM can be implemented on a project, the project organization needs to understand the concepts behind EVM. Otherwise it just becomes a metric that “my boss says I have to include” versus a metric that identifies project problems early.

8. The PM staff has a high level of project management experience and maturity as evidenced by process quality assurance audits and skill assessments.

Project management maturity is another critical success factor. If the concept of project management is a fledging activity that is non-value add, then an earned value implementation won’t be successful. Organizations that use EVM have a mature project management staff that understands the value of project management as a role and discipline within the organization.

9. The project managers in the organization are PMP certified as evidenced by a count of all PMPs in the organization.

In today’s market, obtaining certifications has become somewhat of a commodity. In a weekend, I can take a PMP preparation class and have enough practice to take the exam. Despite the commodity debate, having a PMP certification ensures you have common language with your PMP peers and all should have an understanding of earned value management. EVM is covered on the PMP exam and is a good indicator if the project staff has a baseline understanding of the concept.

10. A designated PM is assigned to manage each project as evidenced in a project roles and responsibilities matrix or project charter.

This assessment statement is another indicator of project management maturity. If the role of a project manager isn’t defined for the project, the notion of earned value management becomes an obscure and theoretical concept. The project team will have bigger project challenges that EVM can’t solve.

In my assessment, these were the top 10 of 40 assessment statements based on the project management community responses. Future extensions of the research involve consolidating the 40 assessment questions into a smaller subset for faster assessments. Do you agree or disagree with the top 10 assessment statements? What other assessment questions would you ask prior to implementing an EVM solution? Please comment in the section below.

PM Service Types

The top ten principles for any Change Management

The top ten principles for any Change Management
10/10-Speak to the individual. Change is both an institutional journey and a personal one

The top ten principles for any Change Management

The top ten principles for any Change Management.
9/10 – Prepare for the unexpected. No change program goes completely according to plan.