Category: Operations

We all know the difference between an issue and a risk, right? Well, if we’re not clear, let me explain.

Think of an issue is an event which wasn’t planned to occur on your project but it has occurred and now requires management action. One of your project team quitting mid project; your sales director requesting a change to the requirements; a bug in the software which preventing a database being updated correctly are all examples of issues. Each one will need to be resolved one way or another by someone with authority.

When deciding what do to about an issue, it’s important to weigh up the pros and cons of taking a particular action i.e. what will be the benefits versus the costs of taking the action?

A risk on the other hand is an event which hasn’t yet happened. It might happen at some point in the future, or it may not. Risks therefore are about uncertainty. Perhaps there is a risk of your supplier going bankrupt, a risk of your business critical system software not working properly, a risk of you crashing your car on your way home from work.

If the risk event does eventually happen however it will have an impact on the project, usually in terms of cost, time and benefits, but maybe also on scope, quality and other risks. It’s therefore important to try to qualify these impacts before they occur. If your supplier does indeed go bankrupt during your project, you will need to find an alternative supplier which will likely incur additional costs and might well delay the project.

Precisely because risks are uncertain, it’s important to estimate the likelihood of the event to occur i.e. that your supplier will go bankrupt? You will need to make an assessment based upon your understanding of the situation.

Depending upon the likelihood of the event occurring and the impact if it does occur, you can then plan one or more mitigating actions in response. Whichever actions you plan however, must be in proportion to the level of risk. In other words, for risks which have a low impact and medium or low likelihood, you might decide to accept them i.e. do nothing about them.

For risks which have a high impact (let’s say on costs), and medium or high likelihood, you might decide it’s worth spending a reasonable sum to reduce the chances of the risk occurring. If by selecting the cheapest supplier, you run the risk of them going bankrupt, you might decide to choose another (and potentially more expensive) supplier if you consider there is less chance of them going bankrupt.

So can a risk become an issue? Absolutely. Let’s say your supplier did indeed go bankrupt during your project. At that point there is no uncertainty any more. The fact now is that the uncertain event (the risk) has occurred. We didn’t plan for the supplier to go bankrupt but we now need to do something about it. It has now become an issue and a suitable decision will need to be taken by someone with authority.

As you can see, risks can become issues, but they can stay as risks forever if they never actually occur.

Brainstorming risks early on your project, putting in place mitigating actions and tracking these consistently throughout the project are all part and parcel of being a project manager. Keeping track of issues and taking sensible decisions accordingly are also part of the day to day work of the project manager.

What were some of the biggest risks which you had to deal with on your projects? Looking back, could you have dealt with them any better? I’d be happy to hear your stories.

One of our recent projects involved work to be done on a short, 3-month deadline. According to the project leadership, everything which denoted good project management practices had been performed.

The work was scoped, fine-tuned, and broken down into work packages. The work packages were then assigned resources and budget. Budgets and timeframes were confirmed with the actual performers of the work. Inspections and progress tracking were built into the schedule. Planning went on and on. By all counts, the project should have gone smoothly.

In hindsight, the first sign of trouble should have been the payments. The contractor performing the critical “Stage 1” in month 1, had agreed and signed a contract for milestone payment. Yet he approached management every week with reasons why he needed an advance, or needed management to cover certain expenses. As a sign of goodwill, and given the tight deadlines, management approved the payments. They figured these interim amounts would just be subtracted from the final milestone payment, so all would be well.

Soon, it was quite impossible to correlate invoices with actual progress achieved on the different work items. At the 1-month milestone review, the contractor said items were 90% complete, whereas the customer’s tester rated the progress as much lower.

Management became hugely concerned. Not only was the critical first stage not been finished in month 1, there was no agreement on how much work was actually completed. They decided it was best to pay the contractor for work performed and go with another, more experienced contractor for the remainder of Stage 1. So Management went back to the contract, to see what clause to invoke to terminate this sub-standard contractor.

To their great consternation, the agreement only included termination for breaching the contract, not “termination for convenience”. Otherwise, there was a clause for dispute resolution, which included an outside mediation group. A great battle ensued, where the contractor did not accept they were in breach of the contract. Their position was that they had had a few delays, but would remediate all incomplete items. If not allowed, they would sue Management for the entire value of the contract. The Management team found this stance unacceptable, and hired another contractor to finish Stage 1, since they had time pressures.

To this day, that contractor and that management team are mired in submitting paperwork to the dispute resolution mediators. The contractor claims he is owed the entire value of the contract. The management maintains that those interim payments made to the contractor are equivalent to the incomplete work in Stage 1, and not another cent will be forthcoming. So the inspections, submissions, and document reviews continue with the dispute resolution group.

In summary, include in your contractor agreements a clause on “termination for convenience”, whereby you can pay them for work performed up to a certain point, and then part ways without further explanation. A point may come in the project where you have to be able to -as they say in the performing arts- exit stage left ….

Is that often they aren’t too familiar with their responsibilities on projects.

That’s a rather sweeping statement you’re thinking and you’d be right. In my experience, senior executives who have committed to funding the project often don’t have the inclination or the time to learn more about project management. And that’s leaving aside the fact that they are often too busy managing the business anyway to devote much time to your project.

These factors combined often means that the project manager is left without the direction expected from the sponsor.

I remember a conversation with a senior project manager at a UK government department. He was complaining that as soon as parliament closed down for the summer the sponsor jetted off to his villa in Tuscany for 4 months. Not only that, but he refused to leave any contact phone number or contact details with the project manager. So, when issues came up during this period, the project manager was either left waiting for several months, or was forced into taking a decision beyond his authority.

Lack of sponsorship was identified by the Standish Group in their Chaos Report as one of the most important reasons why projects fail. Of course, there are always some projects with active, committed executive sponsors who know that their role is to direct the project and to take the big decisions whilst delegating day to day to the project manager. These projects stand a much higher chance of being successful compared to those with non-committal or absent sponsors.

So what can you do as a project manager to try to avoid this scenario? Well, the truth is, there is no silver bullet.

You could identify the sponsor’s potential lack of involvement as a risk early on and use this as an opportunity to discuss with the sponsor the expected level of involvement. Crucially, it will be about agreeing when key decisions need to be taken by the sponsor and trying to ensure their availability at these times.

You could try to educate them about their responsibilities on the project, but don’t expect that they will want to sit through a training course however.

More fundamentally, if you find your sponsor going AWOL shortly after committing the project budget, then this is a sure sign that your project is on the road to failure.

Guest Post by Danielle Garza

We’ve all been there before. When it has to happen it can be a frustrating process to go through, but it happens to all of us at some point: a highly visible or mission critical project in midstream needs to have one or more key project resources added or replaced. And we all know that how we handle this process on our project and with the client can mean the difference between success and failure on the engagement.

Company resources need to be replaced for a number of reasons. Maybe a key project resource was needed quickly on a new project. Perhaps an employee left the company to accept a job with a competitor. Or it may be a case where an employee was let go from either the company or possibly just the current project due to performance issues. Whatever the reason may be, leadership is now faced with the critical task of onboarding a replacement, earning client acceptance, and getting the new resource up to speed and productive as quickly as possible so the progress on the project isn’t hindered and so the project customer continued to see seamless delivery.

To ensure that this happens, some key steps should be followed. Let’s assess these in detail:

1. Find the replacement.

When it comes to identifying a viable candidate, usually there isn’t a shortage of talent – the key is to find the right talent and ensure they can be available to fill the project role for the duration of the engagement. The last thing you want is to make yet another change farther down the road.

The hope is that you’ve already informed the client that a change is in the works at this point. If not, this happens to be an appropriate time to do a quick introduction of the new project team member to the client. Give the client a summary of the new team member’s experience and background, as well as identify the key experience that makes them a qualified member of this team for this project. The goal is to instill as much confidence in the client as possible.

2. Transfer knowledge.

Secondarily, perform as much knowledge transfer as you possibly can to the new team member. The best source of information for the onboarding resource is obviously the outgoing team member, however a call on the entire project team to bring the resource up to speed during an internal team meeting will suffice. And supply the new resource with the latest project info including the latest project status report, the latest project schedule, the current issues list, and the statement of work and kickoff materials from the start of the project. They need to know the status of projects, what they will be held responsible for, and what the overall goals and objectives and high-level requirements are.

3. Educate and shadow the new resource.

The next steps should include a ‘shadowing’ period of 1-2 weeks where the new resource remains in the background on status calls with the client while they are being brought fully up to speed. This makes the transition as seamless as possible for the project client while also setting up the new resource to be as knowledgeable and productive as possible when they take over the role.

4. Move to full productivity.

Finally, what must take place is the move to full responsibility client facing. At this point they are fully independent in the new role and are representing the team during key client conversations and participating as expected during the regular weekly project status calls with the client.

Summary

The bottom line is that if leadership and the project manager follow a carefully planned path similar to what we’ve discussed here, then the transition from the old to the new should end up being handled efficiently and effectively. The goal is to keep customer confidence and satisfaction high during a transition like this, and by following a planned process that includes the steps described above rather than rushing a replacement in too fast with poor preparation, the project manager is much more likely to achieve that goal.

Danielle Garza writes articles for Tenrox cloud-based project management software.

Have you ever worked on a project where you asked “what’s the point”, or felt that you shouldn’t be wasting any more effort on it? I have, and it makes you wonder who is really in control and whether they really understand why a Business Case is essential. I’ll give you an example.

Some time ago, I was asked to take over the management of a project 4 months in because the previous project manager was moving on. The project would deliver an I.T. system which would interface with a data feed containing financial trade data, do some calculations and then dump out the results into some reports and files.

Pretty simple really, although for reasons I won’t go into the developers had chosen a solution which was way over-engineered. The end result was that the system was beset by quality problems. This was coupled with the fact that the data feed which was being developed by another project wouldn’t be ready for another 6 months.

I raised this with my boss who was in overall charge of the development and he said it didn’t matter if it didn’t work – in fact it had failed all tests until that point – but what was important was that it was delivered into the data centre on time. So, I dutifully obliged, and ensured the server was delivered on time, even though it was just a useless box sitting there doing nothing because there was no data to process, and no ability to process it anyway.

So why had my boss insisted on wasting time and effort installing a useless box with unusable software? Simply because his bonus depended upon him showing he had met his targets. The project was for a very large and very successful international business which just goes to show even in huge successful organizations there can be an alarming lack of understanding about project governance and business justification.

On this particular project there wasn’t a Business Case which described why we were doing it, or quantifying the benefits which would result from it. In other words, there was no justification for the investment of time and money which would be required. As it turned out, after a year the project was eventually cancelled, primarily because of the ongoing quality problems associated with an overly complex technological solution.

In retrospect the organization could have saved itself a whole load of money by not proceeding in the first place. This decision would have been made easier had a Business Case containing a thorough cost benefit analysis been developed by the organization at the start.

Can any lessons be learned? Yes, firstly never start a project without a Business Case and secondly, educate more senior decision-makers in the necessity of project governance. Whilst the first is much easier than the second, both are essential to ensure your organization doesn’t waste even more time and money.

Have you worked on projects which were a waste of time and/or money? Do your projects always have a Business Case?

An interesting development has been taking place in my international projects, regarding the allocation of time. Many of us in the business of implementing projects have heard of that very useful device, the “triple constraint”, right? Simply put, it is a framework to help us balance the competing demands of the project by having customers and performers agree on the Scope, Time and Cost components. It is good guidance in our efforts to organize and subsequently deploy the project work, and can be used iteratively at many points in the project lifecycle.

Once the scope and durations for activities have been agreed, I notice that colleagues from some countries will work linearly, sticking closely to an order of events and to a critical path, while colleagues from other countries will work on two or three activities at the same time. This latter approach makes progress reporting a bit trickier, as parts of the project will start before their immediate predecessor has been completely finished. It also means that more of my tasks remain open at 75%, or 90%, taking longer to reach the full 100% completion.

This reminds me of buying cheese in Europe. At the cheese shop in Germany, little numbers were issued on entering the shop, and customers were served in the order of these numbers. As many cheeses as the customer wanted would get duly taken out of the refrigerator, unwrapped, sliced, and wrapped again once the customer got to the front of the line.

In Spain, while customers did queue, when the one at the front asked for a pound of Gruyere, the shopkeeper would shout: “Anybody else need some Gruyere?” He might then serve two customers at a time: the one at the front of the queue and another one from the middle of the line. I cannot imagine being successful in the German cheese shop if, from the back of the queue, I were to shout: “Hey, can you slice me a pound of the Gouda while it is out?” I am sure customers and staff would have been horrified at the mere suggestion.

The perception of time and how to fill it vary greatly by culture. Some countries value planning and organized execution tremendously. In some other countries, staying flexible, re-prioritizing at the last minute, and working on two things at once seems like a better system (By the way, I do think the Spanish shopkeeper sold cheese to more customers by the end of the day).

In our international projects then, what type of project manager will we be? The one that demands work be done in the exact order we have specified? Or a flexible one that allows for the different perceptions of time that different cultures bring, as long as the work gets done…. and all the customers get their cheese?

Guest post by Ian Needs, Marketing Manager for KeyedIn Solutions

If your project management has no formalised frameworks, your business may well be losing money.

Standardisation and consistent application of project management methods, processes and technologies is a key factor in business success.

Project portfolio management (PPM) software provides a centralised dashboard for the meta-management and analysis of multiple projects, so that your project management team works within clear guidelines that design projects to succeed.

Issues Faced by Businesses
If your business manages multiple projects and resources, you may find PPM software helps you to align and streamline your projects.

When project staff work independently without any formal PPM structure, their unstandardized approaches will directly influence the progress and success of individual projects. In some organisations that might be a benefit, but in others it leads to unpredictable performance and non-comparable measurements of key performance indicators.

If you’ve found yourself:

• struggling to analyse performance across projects due to a lack of comparable data
• being forced to make project management decisions without complete information
• suffering the ignorance of stakeholders due to a lack of consistent, engaging communication
• worrying about the practicality of your pipeline management decisions
• wishing for more integrated information on overall portfolio viability

…then it may be time to explore PPM software.

What PPM Software Can do for Your Business
Most professional PPM solutions support the management of project scope, time, cost, procurement, integration, resources, communications, quality and risk.

A good PPM application lets you track and manage projects seamlessly, applying time-saving templates, scenario models and workflows. You’ll be able to take a long-term overview of all projects –past, current and future—to ensure that everyone’s efforts and resources are aligned toward your organisation’s strategic goals.

Some PPM software provides a real-time view, while other options are dependent on scheduled data refreshment. Real-time data is invaluable to its end users: your project managers, resource managers and executives will all benefit from timely insights into resource demand, capability and project delivery.

Who Doesn’t Need This?
If you’re running a very limited number of projects, PPM software is perhaps not an essential for your business. However, it’s a nice-to-have that may become increasingly useful as your project portfolio evolves.

Similarly, if your budget is limited then you may debate the value of PPM software. In a down economy, many businesses do without an automated PPM solution, but this often leads to inefficiency and a reduced ROI. Different organisations have different project portfolio management requirements, but most can benefit from clearer oversight of programmes and projects.

Rather than buying a licence for software that will only be partially rolled-out, it makes more sense for businesses with lower budgets to use easily scalable Software-as-a-Service project portfolio management solutions. PPM in the cloud offers a great deal of flexibility as well as location-independent access to information.

If you think it might be time you got project portfolio management software for your business, consider the numbers, types, and hierarchies of the projects you currently manage. What you’re looking for is a solution that suits your current portfolio and management requirements, so that you can improve your business efficiency without a long and complex implementation phase.

—————————

For more resources, see the Library topic Project Management.

—————————

Ian Needs is Marketing Manager for KeyedIn Solutions, provider of the KeyedIn projects project portfolio management software package.