Project Management in Practice

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

Category Archives: Change

Is productivity gains the answer to improved business outcome?

Is productivity gains the answer to improved business outcomeI recently ran into an old school friend. At the time we were nearing the end of high school he was the coolest dude with a job at a fast food place. He had disposable income and an old second hand car. What else do you need in life? Those of us that were planning further studies or apprenticeships got plenty of advice from him on the futility of our endeavours. When someone mentioned better prospects and better pay, he simply said if he ever needed more money he can simply work a few extra hours.

All these years later I was surprised to see him holding training materials. I was intrigued with this change of attitude. At the time some of us were thinking of investing in our future and as a result consciously taking on a few more  years of hardship, he had no appreciation that his circumstances could change. He shared with me his predicament in working harder and harder to support his family. This larger than life character was backed into a corner. It is great to see him sorting his life out.

What has this got to do with business outcomes you may ask? It occurred to me how many organisations take a similar approach to making money. Everyone is in a mad rush to squeeze yet another billable hour out of staff, minimise non-utilised time. The only certainty is that the environments we operate in will change. As my friend found out eventually, there is only so much difference you can make using this approach.

True sustainable change comes when you have the commitment to review your methods, acknowledge the failings and change accordingly.

Image Credit:

Enhanced by Zemanta

How do I balance competing investment priorities?

Organisations are forever grappling with the demand of competing investments that give a varying range of benefits. How do they go about prioritising these? Most organisations use business cases as a means to filter out the projects that deserve funding from the ones that have little or no merit. This then introduces a secondary problem of spending a lot of resources on going through a business case, which will never see the light of day. How do you make sure weak business cases do not get all the way before getting knocked back.


Investment Logic Mapping (ILM) provides a good way to filter out some of these early investment dilemmas. This is part of the Investment Management Standard developed by the Victoria Department of Treasury and Finance in Australia. The main driver for the development of this standard was the number of complex investments that required compliance, but never articulated the benefits they were supposed to deliver.  Effectively what started as a mechanism to shape individual investments in 2004 has now matured into programme and organisation levels – including refocusing organisations and monitoring benefits.

The theory behind the standard is quite simple. Rather than a complex set of tools, it is centred around three key concepts

  1. The best way to aggregate knowledge is through an informed discussion that brings together those people with most knowledge of a subject.
  2. The logic underpinning any investment (the ‘investment story’) should be able to be depicted on a single page using language and concepts that can be understood by the lay person.
  3. Every investment should be able to describe how it is contributing to the benefits the organisation is seeking.

In Victoria it is now mandatory for most significant investments. In New Zealand the State Services Commission (SSC) mandates the use of ILM for High Value or High Risk (HVHR) projects as part of its Better Business Cases initiative. It must be remembered that ILM on its own is not the tool that will drive the investment. It is a tool to eliminate initiatives which lack merit.

I have just recently undertaken an Organisational ILM as part of a strategic review for an organisation. I have found it an excellent tool to bring out the challenges in an open forum and to agree on strategic responses. The two hour session was perfect to get enough senior leadership in one room to work through the organisational challenges. I also found it a good use of senior stakeholder time, as they are busy people and often trying to agree a course of action individually with all of them is a significant barrier to change programmes.

If you have used ILM before, I’m keen to know your experience. The only thing I had forgotten is being on your feet facilitating for two hours, while everyone else is seated discussing and having refreshments is quite tiring.

Should government be in the business of IT?

I was reflecting on the news during the week that a second head has rolled in the Novopay debacle. After Education Secretary Lesley Longstone, Deputy Secretary Anne Jackson has also fallen on her sword. There has been some interesting commentary regarding the extent government should be involved in IT.

should government be in the business of ITGovernment policy changes as often as election cycles, sometimes even more frequently with change of ministers. It seems quite a common consensus around the developed world that government is gradually stepping away from providing the IT services and replacing with suppliers. I have worked most of my career in the supplier space. Still I wonder if sometimes it provides the best outcome for the governments. There are good reasons to outsource to experts. Are there equally good reasons not to?

In my experience, those of us working in IT have an inflated sense of self worth. We tend to forget that IT is almost without exception an enabler of capability. No one does IT because they need to deliver IT. It is therefore a support activity to help core deliverables of an organisation. It is argued that this activity should be outsourced to experts to deliver. Expertise in IT does not equal expertise in delivering the business outcomes for the organisation. This distinction is not always made.

Quality in any IT service delivery is relative to the the context. You can provide a quality service only when you build up knowledge of the outcomes the organisation is trying to deliver. A good understanding of the constraints are also needed for success. These are constantly evolving. In a usual scenario a number of suppliers will provide a range of services to an organisation. Typically none will have visibility of the end outcomes desired. There are so many instances of projects delivered to specifications that do not deliver business benefits, it is frightening.

The pressure from bean counters to reduce head count has resulted in false accounting. People are very resourceful and learn to manipulate systems to get what they need. By reducing IT head count, the cost is passed on to specific projects. When suppliers are engaged in those projects, government is paying for the actual cost to deliver the project + contingency applied by the supplier + supplier’s profit margin. Even if you retain the same vendor, you are not always guaranteed retention of intellectual property. In reality the cost to deliver the same outcome is no less, and is likely to be significantly more.

I do not see government contracting model encouraging sharing of risks and rewards. Contracting method encourages offloading risks totally to the other party. This results in most contracts being administered in an adversarial way. Where deliverables are provided for a fixed cost, suppliers will always try and deliver minimum that will pass acceptance, rather than trying to maximise outcomes. Where many individual contractors are used, I have seen instances where they have tried to stretch out the delivery in subtle ways.

The role of the government is to deliver a service to the taxpayers. All that is required to deliver the service in an effective and efficient manner should be part of the role of government. A government department has its own legal teams and human resource staff. Why should IT be any different. This is even more critical considering the long list of failed IT projects. Disagree? Let’s discuss.

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.

%d bloggers like this: