Beyond the alphabet soup of PRINCE2, MSP, PMBOK, ITIL, Agile
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
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.
As 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?
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.
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.
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.
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.
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.
I 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.
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.
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?
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.
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.
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.
The saying if you pay peanuts, you get monkeys used to be quite a true one. In traditional business models where all suppliers came from the same market that extended to projects as well. Today services are not necessarily procured from the market they are delivered. Competition is much wide ranging to different countries and even continents. Exchange rates can artificially put companies in an advantageous position. A reasonable salary in India or China will be significantly less than in the United States, Europe, Australia or New Zealand. This pits companies providing services in their own markets into a challenging situation. How can they compete?
Some companies have taken the route of your “local” as the reason to do business with them. Unfortunately, the world is a more savvy place today than some years ago … mostly. This tactic does not work as well today as once it did. The scenario is not limited to services being offered from cheap offshore companies. The response of many companies in these jurisdictions that seek to be competitive is to eliminate overheads by cutting training, limiting remuneration and benefits, removing office locations etc. to provide services on the cheap. Challenges are even higher competing against such organisations.
If you wish to maintain a semblance of quality, retain capable staff and intellectual property and seek to provide job satisfaction then there is a cost to that. The organisation cannot absorb all the cost. They are in it to make a profit at the end of the day. This cost has to be passed on to the client to make it work. Is this a futile exercise? It may seem the only way to compete is to trim expenditure at the cost of everything else.
I was having a conversation with a former colleague, who was of the opinion that he would seek quality every time. While an excellent idea in principle, it rarely works in practice when money is involved. We as human beings are programmed to look out for the best “deal” out there. You only have to look at the roaring trade retailers do around festive season. It is the appearance of value for money that attracts many. Think yourself … if you can stay at a 5 star hotel for 2 nights and for the same cost stay 7 nights at a 3 star hotel, which one would you choose? Maybe you choose a 4 star accommodation for 4 nights instead as a compromise? Companies are constantly balancing quality against cost.
A look at the car industry can help us take a guide in the IT world. Tata manufactures the cheapest car – Nano in India. It is not even marketed outside of India because cheap itself will not sell. There are quality criteria for entry into other markets. US manufacturers have for years relied on being the home brand to trade. As the petrol prices rise consumers have become more aware of better value for money with Japanese cars. At the same time many German manufacturers remain as premium brands that trade less on quantity and more on quality.
What IT companies need to do is to focus on showing value to the customer rather than trying to be cheap. There will be a set of customers that will equate cheap with value. In some cases companies will need to evaluate whether those customers are worth servicing. Some customers will go for cheaper option from an incumbent supplier, rather than an innovative and higher quality option, not because it is cheaper but because they are averse to change. These are customers that you need to keep in touch with if you believe you can offer a higher quality. They may one day develop the courage to change. Focus more on the end of the market that will recognise quality.
How do you communicate this quality? Change emphasis. You are local. What value is in it for the customer? You can respond quicker, have coverage for the full business hours, speak the same language, aware of business processes and local legislations. Trumpet your retention rates and certifications or technical skills of your staff. Build a relationship with your clients outside business – social or sport. You actually have selling points that cheaper ones do not or cannot have.
Image Credit: http://www.webdesignerdepot.com
After nearly a two month hiatus in blog posts, it is time to jump back on the horse. In that time, I have spent five weeks on vacation and either side of it two and a bit weeks in doing handover and picking the work back again. I thought it would be useful to share lessons I learned from this exercise.
The Preparation
This is the most stressful part of going on a long vacation. I had worried about projects suffering in my absence due to lack of control or guidance. Clarity in decision making based on experience is a key skill of a Project Manager. As many Project Managers do, I still carry my cell phone during short holidays. There is always a fallback if the wheels start to wobble. On such a prolonged vacation overseas I was not about to entertain being on call. I therefore asked for a short term stand-in for my role. I involved in various projects during a two week period to ensure he had sufficient background in the processes we followed and status of the projects to carry them through for five weeks.
The Vacation
This was the first vacation of this length I had taken in nearly five years. Having done the legwork with my stand-in, I was surprisingly relaxed during the holiday. I cannot put my hand on heart and say I never worried. Anyone with a level of responsibility will from time to time worry about events beyond their control that they cannot steer their team through. Most of the incumbent project teams and support teams – sales and management – were still there. Needless to say I enjoyed my time off in the knowledge that with the handover I gave and the available support structure the risk of total cock-up was relatively low.
After the Vacation
On my return I was pleased to see three quarters of the activities were done as I had wanted. Some were left for my return that required a level of experience or authority to carry out. While there were some thing done slightly differently, I can accept that as best effort choices based on information at hand. One particular area was done better than I had expected – breaking development work packages into short sprints. The week following the vacation was spent trying to get back to the rhythm of work and getting a handover.
What the team learned
The team understood the consideration, communication and time it takes to make decisions on project related matters. Many a time some of these challenges are nto visible to the project team (or for management for that matter) and cannot be readily appreciated. The fact that quite a few decisions were deferred and a lot of the decisions required quite a bit of internal discussion gave them an appreciation of challenges I deal with on a daily manner.
What I learned
The biggest learning on my part is that I need to worry less about thing going wrong in my absence. My team is made up of some very capable people and are able to provide good guidance on how projects should be executed. I will probably look to see how I can take advantage of that to get some of them to provide more leadership. From a personal point of view, the vacation has enabled me to recharge my batteries and come back with renewed energy. I will also look to ensure my team gets the same opportunity.
It is good to be back. Keen to hear your learnings from similar experiences.
Image Credit: NewHotelsUs.Com
Senior Project Manager at Eagle Technology, APMG Accredited ITIL, MSP + PRINCE2 Practitioner, governance expert, cricket fanatic, squash pretender. Opinions expressed are purely from my experience of leading teams and running projects, and in no way claims to represent those of my employers or customers.
