Project Management in Practice

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

Category Archives: Communication

5 things to do when projects go wrong


5-things-to-do-when-projects-go-wrongAnyone spending a decent amount of time in project management field will sometimes have projects from time to time that experience significant difficulties. For all the planning, it is never possible to predict all the eventualities and therefore foreseeing all risks. Projects are by nature more risky than other business activities. It is always useful to apply a few techniques to aid in such situations.

1. Show leadership

An oft repeated cliché this is something that is hard to explain in terms of action. When things go wrong there is plenty of nerves in the project team and management. Project team members often struggle to think beyond their immediate problem. You will find internal executives or sponsors worrying about contractual obligations and any fallout with the customer. Showing leadership in this context is to ensure this uncertainty does not spread into panic. The role of the project manager is to steer a clear course and stopping any blame game that may raise its ugly head. Now is not the time for that. Focus on why after the project.

2. Avoid temptation to simply throw more resource

A common reaction to a struggling project is to throw more resources at it. If the project is of high visibility and management is not able to provide subject matter expertise, they will feel they need to contribute somehow to correct it. The commodity at their disposal is resources. Be wary of this. More cooks do not equate to a better dish. You may need to enlist some mentoring for project team members or even yourself if you are managing a project outside of your technical expertise. Always consider how much time it will take before new resources can contribute to the project. If the issue is time, you will virtually ensure a delayed delivery by adding resources. Also take into account the additional communication required to successfully integrate them.

3. Avoid sugar coating

There is a temptation to play things down as things start going wrong to avoid creating panic. I have found it easier to be transparent about progress. Late surprises will compromise integrity of the project like no other. While your stakeholders likely be upset with you, in the long run it will get you more respect. You need to be clear with communication internally. If you need some of your resources to be allowed uninterrupted project time, you need to give that clear sense of urgency. Otherwise, you will not get the outcome you desire. Clear does not mean antagonising your people. You may need the same people later in the project or for a subsequent project. Do not burn bridges.

4. Undertake review

Very often when a troublesome project is completed, people are so pleased to see the back of it, no learning takes place. This is just about the worst thing you can do. You are not making sure same problems are not repeated. Wait for a reasonable period after project closure to undertake review. While things are still raw, people are more likely to be defensive and the value you get from the exercise will be limited. When you review, structure it so everyone has the ability to come forward with what they could have done better. Start yourself to show the way. If people are forthcoming, leave it at that. Your aim should be to avoid repeat, not to be punitive.

5. Follow up

Do not leave the review in a document and expect the next project to pick up on it. Use the information from your review to recommend training plans and process changes for the organisation. Present these to someone with influence within the organisation. After some time follow up on progress of the recommendations. Improvement takes hard work and tenacity.

Do you have any rules for managing troubled projects? I’d be very keen to hear.

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.

How much do you think it’ll cost?


How many times have you heard that? “Oh, I’m not going to hold you to this, but just a ball park figure?” Sounds even more familiar? And now the clincher, “You know our systems, surely you have an idea.” Trying to answer this sort of question from the client too soon causes enormous headaches in projects.

Cost is something that is never a black and white answer. Cost of the same project will differ markedly depending on what technology and process choices you make, what functional and non-functional standards you sign up to, how much of the subject matter expertise your clients are willing to provide to the project team and even some mundane things like what time of year you want the project to be implemented. A cost estimate therefore must accompany the scope, assumptions and conditions that it is based upon.

Many times you will have technical staff working with clients that will be put on the spot by these kinds of questions. They will have the best interest of the client and their own organisations by trying to answer the question. Unfortunately, this sets the expectation of cost from the client’s point of view. Some of the technical staff may be very skilled in their own responsibilities, but may lack the full project life cycle knowledge. Therefore the risk of underestimating or completely missing required activities is high.

In all likelihood the client has not had the time to frame what it is that they want. If they have a figure to go by, they will form the scope in due course and wrap that around the figure. This happens inevitably, even if there is significant gap between any cost figures you may have provided and when they had the time to form scope. There may not be any malice involved at all. This is how we as human beings operate – piece together bits of information to build the picture.

If you try to reset the expectations of the client at this point, it is tricky. There is always a chance to give the impression that now that they are interested, you are trying to squeeze them. Chance to set the correct expectation has long gone. By trying to be helpful, you have a situation on your hands.

You may come up with the same situation with your sales staff as well. They may be the ones that are responsible for communicating costs to your customers. Your challenges will be equally as pronounced if they miss the caveats. There is a fine balance between the cost appetite a customer has and the benefits they wish to gain from a project. In the quest of landing a sale you should not set a project up for failure. If the project is a keenly desired one for which your organisation is happy to make a loss on, then your management must be in a position to knowingly take the risk on. This should not come as a surprise during the project.

How can you go about ensuring the correct expectations at the outset? The first thing I make a policy on is to never provide estimates on the spot. I have only seen bad outcomes in trying to do that. Have standard estimating methodologies that you follow. The methodology may be different depending on the type of project you are managing – i.e. software development, construction, policy development etc. But there must be a methodology. Document the risks, assumptions and constraints that accompany the particular estimate. This way once the customer has had the time to think of the whole solution and the cost is different than the first one you provided, you can have an open and honest discussion on why that has transpired. This must extend to the whole team. Train them to tell the client that they will take the information back and follow up with an estimate.

First impressions do last long with customers – especially when costs and timelines are involved.

Expectation is reality


We hear about perception being reality in service management space. When you are dealing with projects, expectation become the be all and and end all. How your project is perceived is proportional to the level of expectation about the outcomes that you have built.

Expectation Management

In the project paradigm, cost is the easiest attribute to communicate. If the expectation in the business is that a particular deliverable will cost 100 hours and your team delivers it in 105, it will receive somewhat begrudging acceptance. 110 will get people thinking whether it was worth the effort. Conversely, if you had built the expectation that the cost would be 120 hours, then even if you spen 115, the business will consider it a great delivery.

This may sound non-sensical, but it is the truth. How does one go about building this expectation? Do you just inflate estimates to achieve this? You cannot necessarily do that. If you are a monopoly supplier like inhouse team, then you may be able to get away with consistently over estimating the effort. In a services business, there is competition for this work and you do not want to turn away business by being too conservative.

At the same time, you do not want to be forever undercutting your competition to get work. In that scenario, you are always left with the scraps to fight over. You are in it to make a profit. If my cost is going to be more than my fees, then it makes no sense to take the work on. This can be a difficult juggling act unless your sales and services teams work closely.

Expectation is not only some thing that you as a Project Manager end up managing from the customer side. What is a good project from a deliverables point of view, may not be a great financial success. If you are running a project on a time and materials basis and are accomplishing things much quicker than anticipated, you are in fact depriving yourself of income. How do you avoid that? I recommend undertaking additional testing and documentation to ensure higher quality.

If the same project is being delivered on a fixed fee basis then the drivers are different. Your motivation now is to ensure the minimum effort you can spend to have the outputs delivered. You can make good profit by being efficient. Yet, some customers will begrudge that. Your work may have saved the client 100 hours of pain and priced accordingly. But if you achieve that in 80, the client is upset with you being accused of taking them for a ride. Yet, the same customer conveniently forgets that you carried the risk on this and had the project taken 120 hours, you would have been forking out services for no fee. We want to have our cake, and eat it too.

Then here are always those projects, where the customers have a want that is far out of proportion of their cost appetite. Be wary of this. It is a very common occurrence. It may sound like a good idea at the inception of the project to sharpen your estimates to land the work. This can only lead to bad work. You are setting the project team up to having to cut corners. If you really have to discount, do so on the basis of rates. The work is what it is. There is no up-side to compromise on quality.

What makes things difficult is that there is no right or wrong answer. It totally depends on the environment.

Image Credit: pretensesoup.wordpress.com

Have Project Management tools kept pace with time?


I have recently been looking at optimising the way we manage projects. One thing this has led me to think is whether some of the project management tools have kept pace with the way people work today. I am not looking to re-invent the wheel. Neither am I wanting to be lazy. I am after a way to effectively manage delivery by utilising all my resources to the best of their capability.

Projects have been undertaken since humans first realised they could organise themselves into a unit to achieve mighty things. Even before the discipline of project management was a recognised one, we managed to build the pyramids, the Great Wall and the Taj Mahal to name a few. Does that mean it is a profession that exists for no purpose? That is not true. Many of these projects were run by autocratic rulers who had no regard for human life. All three of the projects I mentioned cost the lives of thousands of workers. Fear for life was a successful motivator even as recently as a few decades ago in the communist Soviet Union.

As we have realised fear alone cannot achieve good outcomes, we have put in effort into devising methods to manage projects in a predictable manner. We have many methodologies – most of them very mature. But it seems applications have not matured to the same extent that methodologies have. It still amazes me how many organisations still manage projects by using Microsoft Excel. The next most widely used application I have seen is Microsoft Project. That however has seen no useful upgrade between the mid 1990s, when it first came out and 2010.

Microsoft has realised the folly of that approach and has been concentrating on their enterprise offering of Project Server. I have previously posted about using Project Server and utilising it to identify resource gaps. Having used it for a few years, I have come to the conclusion that it takes considerable effort to keep updated. Unless you have a PMO with enough resources to stay on it, it is nearly impossible to use effectively. Interestingly, LiquidPlanner has taken a different tack to managing projects by accommodating uncertainty through a high and low effort estimate. That is a very useful method if one is using it to manage product development. However, I was unable to find a way to use any sort of baseline that would allow me to track how the overall project is going compared to the original plan.

I have been trying to think what would make a project management tool stand out from the rest. I want to get away from managing in a hierarchical manner Project Managers have traditionally operated in. I want to ensure that the people working in projects I manage have the ability to raise risks and issues with a minimum of administration effort. I want to know the status of projects as close to real time as possible, but not have to chase up for updates continuously. That only serves to annoy technical people, and is a complete waste of my time.

This is the age of social media. People are used to collaborating in all aspects of their life. Being connected is not a bad thing. The project management discipline can benefit from this constant connectivity. If done well, it can provide early visibility of risks and issues, provide a platform to share ideas, sharing knowledge and lessons learned. Having a mobile presence is a must to achieve this. Some of the Agile product management tools have done well in this respect. Another complicated factor is the need to integrate the output from this with billing or ERP systems used by the organisation – in our case SAP Business One.

My search is yielding mixed success. I have been looking closely at two products – WorkFlowMax and AtTask. Both seem to fulfill most of what I am after. I am keen to hear from you if you have tried something similar. What has your experience been? Have you found any products to be good in the areas I am looking for?

%d bloggers like this: