Project Management in Practice

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

Category Archives: risk management

What responsibility do outsourcing organisations bear?

Savar_Jeans_BloodI have taken a bit of time mulling over this post. I was born in Bangladesh, but have been an expat for most of my life. As I looked on in horror at the calamitous scenes from the garment factory collapse in Savar and the outpouring of grief from various quarters, I could not help but think if the likes of Walt Disney, Diesel, GAP and Walmart are in some ways not partly responsible for it. What of my own profession where I have managed projects where I have been both the supplier and customer in outsourcing situations … how much effort did I really put in to ascertain conditions?

Let us look at the motivations of outsourcing. There are usually one of two reasons to outsource. First an almost without fail the reason is cheaper supply cost. A secondary reason I have sometimes dealt with is rapid mobilisation, which in New Zealand context is difficult to do simply because of the size of the market. It is probably unfair to even try and compare projects I delivered as the sub-contractor, as the working conditions here are in no way comparable to the scenario in Savar. However, I did utilise sub-contractors in India for some projects. Did I really try and explore if conditions are great there? How are they able to mobilise so quickly. What happens after the project is complete? Not really, I just assumed that someone in the executive had done that due diligence. Never occurred to me to check.

Can this lax attitude be excused? Companies spend a lot of time selecting suppliers with the correct skill set, that can deliver on time, have the correct quality control measures. Should they not be expected to provide equal oversight to the working conditions? This becomes quite a thorny issue. They are engaging the supplier for a set of services or products. They can legitimately expect working conditions should be responsibility of local administration. Many of these suppliers serve many masters. Who should then be responsible for conditions.

Even if these companies are willing to take on the burden of ensuring good working conditions, can they really achieve that? The building that collapsed housed five garment factories and had an A category safety certificate from the Fire Service, even though the entire construction has been documented to  be illegal. Local officials have obviously been on the take for some time to allow the construction and then issuing of false safety certificates. No reasonable person can lay the blame on the outsourcing companies for such failures.

Pope Francis called the working conditions as modern slave labour. There is an element of truth in there. However, one must be careful not to judge conditions through western standards only. $38 buys a lot more in Bangladesh than it does anywhere else. This industry also employs 4 million workers, same as the entire population of New Zealand, 80% of them female. It has given a large section of the community a voice and self reliance that never existed before. Those protesting in front of these companies to stop doing business in Bangladesh must remember that would hurt these people more than the owners.

The world runs on influence. What these companies have over many of the suppliers is leverage. They use this every day to drive down their procurement costs. They should use the same to better the working conditions. As these companies have found out, there is a reputation risk even if there is no legal obligations. Treat the working conditions in the supplier environment as a risk that needs to be managed like any.

Where there is a will, there is a way. The world came together to end trade of conflict diamonds and apartheid in South Africa. Surely some social responsibility is not too much to ask.

Image Credit:

How do I construct the perfect project estimate?

I went to the New Zealand PRINCE2 User Group Wellington Chapter meeting on Tuesday night. As usual the calibre of speakers were excellent. Conrad McDonnell and Barry Calvert spoke on various aspects of estimation. It was quite interesting perspective, one from an IT/vendor angle and another a construction angle.

Importance of a shared vision is not something that I had previously connected to a good estimate. Conrad was quite persuasive on his argument on the need to understand the vision as a pre-requisite in this respect. It is amazing how many projects I have worked on that has started with not all stakeholders having clarity on what what success looks like. Here I do not mean success delivering to a set of agreed deliverables, but something that would advance a measurable business outcome. I can see his point of view. He gave the example of the NASA programme to land on the moon and the vision that John F. Kennedy outlined in his speech.

Perfect Project Estimate

He talked about the vision in the context of a progressive estimate with increasing level of certainty. The key to any good vision is to not assume it is understood by everyone. It must be communicated with a feedback loop. Before the programme or project begins, high level planning must occur. The key to estimation at this stage is to understand your levels of uncertainty and recording your risks. It is key to remember there will always be different levels of certainty at all stages in your project or programme. In an IT context, you may have near certainty about cost of hardware, but little clarity on required design effort. As you execute, you must continually plan, execute and re-plan. Expect to take a few detours on your journey. This is where clarity of vision will help.

Barry talked from a construction point of view and had an analogy of a pancake. It only has four ingredients – flour, eggs, baking powder and milk. Flour is the one that determines the size – what is required, by whom, when – the basic facts. That sets your base criteria for estimate. Eggs are what sets your environmental conditions and is complementary to your flour – what environment is it being delivered, the intended use, slope of the land, other influencers. Baking powder is what gives it the fluff – the nice to haves – types of finishing, flooring, fittings etc. Milk is what gives it the consistency – this is your repeatable methodology and constant refinement of it. Even though he gave the example from a different industry, I like the principle of it. I have a feeling I will re-use it.

One thing that was clear from both speakers was the folly of trying to go back to the customer with a number too early in the piece. Whatever you do, customers forever remember the first number or date.

There is nothing called a perfect estimate. You can only ever get reasonably good at it.

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.

5 Project Management Reflections on Novopay

NovopayI have been reading some analysis of the Novopay saga – some in project management domain, others in the media. Those in New Zealand will have seen the project on the news every week for the wrong reasons. For those outside New Zealand, it is the payroll system to pay 110,000 teachers in New Zealand that has been re-developed from an older platform. The ministry of education website has considerable information, released under the Official Information Act. While it is tempting to point and have fun at the misfortune (or mismanagement) of others, it is probably far more useful to look at it through a critical eye to learn the lessons.

1. Should change of product have led to change in supplier?

From the documents I have read, there has been at least two rounds procurement. The first round had selected the Alesco software product from Talent2. At some point, this procurement was cancelled and a new request of proposal was sought for custom development. If you look at history of Talent2 as a payroll outsourcing provider, they have done it through acquisition, rather than developing their own. Since starting with Alesco, they have acquired several other products over the last decade. If software development was necessary, I would have expected it to go to an established software house.

2. Does RFP provide best procurement outcome?

From my experience it is almost impossible to capture all requirements at the outset for a complex system that has developed over many years and has lots of variations depending on size, geographical location and even available candidates. People in the head office usually do not have a full picture of how things are done in the front-line. Companies will base their price based on the information available and the risk they are taking on. Any changes will be guarded zealously to ensure an on-time and more importantly on cost delivery. Even though PwC undertook a review of the procurement, and this is the standard procurement model for all things government, does this serve such system development projects well?

3. Can a different procurement model work better?

Changes are inevitable in such a large scale system development. There are many assumptions made when responding to an RFP and respondents will contest any adjustments to those. It costs more to do things well. If you know you are competing with other organisations the reality is some of these costs are minimised. Any modifications are therefore contested vigorously. No-one can guarantee what level of time may be required to answer questions, collaborate with subject matter experts etc. One can assume, but it is nearly impossible to validate ahead of the project. Therefore tendency exists to do as little as possible if it looks anything like above assumption level. RFPs therefore set an adversarial relationship, rather than a partnership. A contracting model where government retains the risk of scope, but partners with a supplier could lead to a far better outcome. As the risk is reduced, government should be able to extract a lower rate and remove the risk premium from the supplier.

4. Who decided to go cold turkey?

This may not have been a system that had an impact of life and death, but it is as close to that as it comes. Many teachers have been significantly overpaid or underpaid and the stress it has given to the payroll staff is near breaking point. It is people’s livelihood. Teachers do have to pay their way, have mortgages, children to educate etc. The approach should have been to go live at selected schools, iron out issues as they arose and bring other schools gradually on board. This way the support staff at Novopay may have had a snowball’s chance in hell of responding to the issues on a timely manner, rather than getting completely swamped on day one.

5. There are no winners when blame game starts

I doubt if all the fault lie with Talent2 as has been portrayed in some quarters. Everyone involved – the ministry, decision makers in the project, the supplier Talent2 and their sub-contractors carry varying levels of responsibility. It has compromised the reputation of the supplier, cost the jobs of some senior staff at the Ministry of Education and  forced ministers into public apologies. I will not be surprised if it heads to the courts for compensation. Regardless where the proportion of the blame lies, when everything hits the fan, there are no winners.

It is easier to be wise in hindsight. This post is just my reflections on the matter. Not all of it is mine alone. I will acknowledge I do not have complete facts to judge everything. An audit is being undertaken by Deloitte.

5 Questions every Project Manager must ask

5 Questions Project Manager must askProjects are inherently risky endeavours and require plenty of shepherding to ensure successful completion and the desired results. Key to successful project management is clarity of understanding on what you are trying to deliver. It is easier said than done. Different people can read the same requirements and have different impressions of deliverables. I’ve been thinking about some of the strategies I have used and seen successfully applied. Following is a set that I have found very useful. I find asking some, if not all of these questions consistently gives me best chance of success.

Q1: Can I focus on outcomes rather than outputs?

Most projects in my experience are too preoccupied with delivering the outputs. Predominant procurement methods are partly to blame for the culture of judging project success by its outputs. For example, an output may be a new software but the desired outcome is faster processing of orders. No one has monopoly on good ideas. In many instances requirements are gathered prior to projects starting, where assumptions fail on first inspection. Ask yourself if you have the ability to go back to the stakeholders if you were faced with such a scenario. If it is output that you must produce regardless of outcome, then your chances of success are low. On the other hand, if you know what the desired outcome is, you can articulate why a particular option may have more merit than another.

Q2: Do I have enough sponsor involvement?

I see plenty of projects languishing with project managers struggling to get buy in from various stakeholders. Any organisation is a political one by nature. There are stakeholders with various views. Some may have been keen to undertake the project; others may not have been so enthusiastic. Organisations have to prioritise their portfolio and you may require contribution from those that had their projects or ideas passed over. If you try to manage your way out of that, there is little hope of success. This is where involvement of your sponsor is key. They are usually in a position of authority to ensure cooperation, provide you with strategies to work within the organisation and remove obstacles before they become showstoppers.

Q3: Am I working to artificial deadlines?

I see many instances where projects are running to particular deadlines not because of level of effort required, but because someone in management has undertaken to have the outputs delivered at a certain date. Fred Brooks Jr, father of IBM/360 is one of my favourite authors. In his book “The Mythical Man Month” he gives a great example – It takes nine months childbirth. You can put nine women, you’ll get nine children, but it’ll take you nine months (paraphrasing). The effort is what it is. If artificial deadlines are to be met, it must come by trading off scope in the project. Simply throwing more staff at it does not solve the problem. In some cases you may be able to reduce elapsed time by throwing more resources. But beware, what takes one person 100 hours, will not be delivered by 100 people in one hour. There is a cost of communication and coordination.

Q4: How am I going to transition the outputs to the business?

So you have a set of outputs from the project … process, software, document, building … whatever these may be. Now what? The only way the customer can achieve any benefit out of these is once you have transitioned these into the business. I see many projects leaving transition planning to the end. That is always too late. The end of the project is usually a swarm of activity, many planned, many unplanned but necessary. You need to have planned your transition up front. Organisations have various levels of change appetite. You need to consider if you can take a big bang approach or need gradual transition into service.

Q5: What does my gut say?

If you are an experienced project manager, then trust your instincts. Our brains are programmed to catch patterns. You may get a feeling that something isn’t quite right. I have seen project managers ignore that if they have not been able to verify if there is indeed a need for concern. By the time they have realised what it is it is too late. If your gut tells you something is wrong, stay at it. Until you find out what it is. Have a method that you apply to it. Go through your risk register, deliverables, product descriptions, milestones. At first if you don’t see it, stay vigilant. Ignoring it is just about the worst thing you can do.

There are bound to be plenty of other questions that you should ask yourself. What is your list?

Image Credit: All-Free-Download.Com

%d bloggers like this: