Project Management in Practice

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

Tag Archives: Steven Joyce

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.

5 Must dos for recovering failed projects


NovopayAs I was writing my last post on Novopay, I was also contemplating how one can rescue such a project. The minister in charge, Stephen Joyce has announced a $5M fund for addressing the issues. How would this work in real life? Reports are rife that the government wanted to get its money back from Talent2. That, along with the fact that relationships are already at breaking point, are not good success factors for the project. So what are some of the things that need to happen before you can achieve any improvement?

Acknowledge the failings

When doctors treat patients with substance abuse, the first thing they try to instil on patients is the acknowledgement that a problem exists. The environment around failed IT projects is exactly the same. It lurches from one problem to another while trying to apply band aids to keep things going. Until parties are willing to admit problems exist, there is no hope for a resolution. If you keep doing the same things there is no chance of the result being any different than what it is today. It is very likely that some within the project saw the train wreck coming and may have voiced it. Seek those out to understand what went wrong.

Divorce emotional investments

One of the basic practices of IT is that software developers do not test their own code. It is not because they are not capable. In fact, they should be more capable than anyone else. However, as human beings we are predisposed to not finding holes in our creation. Same is true for the management of the project. The current status is a reflection of many decisions taken through the course of it. Many in the management will feel the decisions were correct at the time with the information they had at hand. You need to remove the management decision makers from both the supplier and customer to ensure progress. Leaving them intact will risk required changes not happening. If the changes do happen, it risks those people losing their authority as they have been “proven” wrong in hindsight. To top manager from the public service, Education Secretary Lesley Longstone has already resigned. If the same has not happened from the supplier Talent2, that needs to happen.

Aim for small wins

In a major failure it may sound couter intuitive to look for small wins, as the problem is a sizeable one. Most adults are reasonably sensible and not easily taken in by bulls**t. They are well aware that a major failure like Novopay is not going to be resolved quickly. What you need to achieve at all costs is some confidence among your user base that improvements are underway and they can see a light at the end of the tunnel. Bigger your ambition is, more balls are in the air and higher the chance of it all coming crashing down because of weak foundations. Identify how you are looking to improve, set target of small improvements often and communicate honestly.

Throwing more resources is not always the answer

As Fred Brooks Jr has pointed out, the most reliable software is written by one or two man bands. The need for quicker output requires many more developers and as a result introduces complexities several folds. One of the major reasons projects fail is because communication is poor. Having large teams working on it is therefore more risky than the original projects. It is a common tendency in projects to throw more resources at a problem. That is just about the worst things you can do in a failed project. With smaller wins go for smaller teams.

Be prepared to abandon the project

For all the best will in the world sometimes you will not be able to retrieve failed projects. Cost of retrieval may be higher than doing another project from scratch. It also may not give you the benefits you were after based on the additional cost. You may find there is more political will to spend in trying to fix something than re-doing it correctly or abandoning it. Be careful to be seduced by that. It is difficult to contemplate ditching a system like Novopay as that cannot be done without a replacement to pay the teachers. Supermarket chains, farms and IT industry contains a lot of similar requirements with a considerable part time contract staff alongside permanent staff with various levels of skills and entitlements. A fully functional system that does 90% of the requirements may be better than an error prone system designed to deliver all of the requirements.

Have you worked on recovery of a failed project? I will be interested to hear your feedback on Novopay or even failed projects in general.

Related articles

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: