Project Management in Practice

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

Tag Archives: Customer

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.

Where is the line between agility and chaos?

We are living in an age of social media. One where opinions are best expressed in 140 characters or less, hashtags galore and needs need to be met instantly. There is a level of agility required to work well in this environment. If an organization rigidly sticks to how business used to be done, more than likely they will be left behind by others that are willing to alter course. However, can one get into the habit of altering so much that they go around in circles? There are many misconceptions about Agile. Let us explore some of those.

Aglie is NOT Agile IS
A methodology Agile is a set of principles.

  • Individuals and interactions over process and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

People have created methodologies around these principles – namely Scrum, Kanban, Extreme Programming (XP) etc.

License to dive straight into code All Agile methodologies have a significant emphasis on continually solidifying user stories. A successful delivery is judged by how closely the delivery met the user stories.
License to develop without scope User stories are the definition of scope. User stories must contain enough information for the developers to quantify a particular story “done”.
License to change your mind daily User stories are worked on continuously. More imminent a story is to be worked on; more time is spent detailing it. Adjustments to requirements are accommodated during sprint planning and treated as any other requirement, which it is being prioritised against.
License to leave half finished work floating around Most agile methodologies will restrict the number of in-flight tasks. If some of the team complete their work before others, it is their role to help others complete tasks at hand.
License to continually chop and change the team Most efficiency is gained when you arrive at a team that gels well. The sum of the capability of the team dictates the velocity at which it can operate at. Constant swapping of resources makes it near impossible to measure progress through burn-rate. One area where you expect change is in the role of the subject matter expert, based on tasks at hand.
License to pull resources mid assignment Once the sprint starts, resources are committed to getting the sprint ‘done’. It is acceptable to commit a resource to part of the sprint or a portion of the resources availability. But once committed, they see it through.
Something that only works on its own Agile is perfectly paced to be used in conjunction with other project management methodologies. For example, one can use PRINCE2 and manage by stages, where the stage boundaries represent iterations in an Agile methodology. Agile requires complete software at the end of iterations. PRINCE2 requires the ability to close a project if the business case can no longer be satisfied. Using the two together allows for tangible benefits to remain with the customer even if a project has to be cancelled.

To avoid chaos, you need a level of planning. When planning is impossible, chaos is the more likely outcome than agility.

%d bloggers like this: