Project Management in Practice

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

Category Archives: Lessons learned

What the Americas Cup teaches us about management


It has taken a few days for the Kiwis to recover from Team NZ‘s slow strangling at the hands of Oracle Team USA in the Americas Cup. In the space of 8 days, they went from 8-1 up to losing 9-8 with skipper Dean Barker visibly distressed. This collapse has been on par with what the national rugby team the All Blacks and the South African cricketers have managed throughout their history. Now that the cup is over, I was thinking if there were any parallels to take away from a management point of view. It appears there may be a few.

What the Americas Cup teaches us about management

Keep improving or perish

In the beginning of the regatta, Team NZ seemed to be sweeping all before them. They won the Louis Vuitton Cup challenger series by a country mile. It was obvious that Oracle started the Americas cup proper undercooked. Oracle struggled to match Team NZ, but kept improving throughout. They were even ruthless enough to drop John Kostecki and bring in Tom Slingsby in the afterguard. It is no different in business. Getting ahead is sometimes the easy part. Staying there is often more difficult.

Resource matters

As I read today about the automatic ‘Herbie’ foiling system Oracle perfected towards the end of the regatta, it appears access to funds does help. While Team NZ itself was funded to the tune of $36 million by the New Zealand government, sponsored by Emirates and plenty of other corporate interests, Managing Director Grant Dalton spent significant time in securing some of these. Interestingly, he was also part time member of the sailing crew. On the contrary, having a single benefactor being able to drop a millions when needed does appear to have helped here.

Survive to fight another day

What made the defeat more hard to take for Barker and his crew is the fact they were only minutes away from winning the cup. Leading 8-3 and within sights of victory, opposition skipper James Spithill decided to take an unexpected route in the third leg of the race. While Team NZ seemed on course for victory, they followed conservative match racing mantra of covering the opposition, so they could not pass them. While Oracle could not pass, it resulted in Team NZ not being able to complete the racing within the time limit. While Spithill could not win that race, he made sure he got the next best outcome. He managed to put enough pressure on Team NZ to force them into mistakes on other occasions as well.

Keep cards close to the chest

The history of the Americas Cup is littered with litigation at every turn. Even Oracle itself had won the cup in court. They promptly changed the deed of gift to prevent the challengers going to court. Despite that, when Oracle was penalised 2 races for skulduggery in the AC45 racing series, everyone expected them to head to court. By not making public their position, they made a very wise decision. Having already won the cup they have no reason to go there. To top it off, they can now take the moral high ground that they would never have gone to the courts in the first place.

For me at least, it seems following some of the cup had some positive after all.

Image credit: TVNZ

When Project Managers can be dangerous


When project managers can be dangerousAs Project Managers we are in the business of control and order. We are placed in a position of trust to achieve the desired outcomes. Most actions we take usually reflect this. The other day I was nearly caught out by something and was rescued by my architect. The worst consequence would have been some lost time in discussion. That made me think, can project managers be dangerous on projects sometimes? I think yes. Here are my top 5.

1. Know too much

This was my problem. Having come from a technical background, I thought I knew something when I only knew part of it. I enjoy keeping in touch with technology and am usually good at knowing when to shut up and let the experts lead. Usually this technical knowledge gives me a good insight to ask questions on approach, probe for weakness. On this particular occasion I could have sent the discussion on a tangent. A position of authority usually brings with it a level of credibility. If you overreach your knowledge there is a risk that people will not challenge it. Project Managers must know their limits. It always pays to have in your team that are willing to ask questions and willing to correct you if you are in the wrong.

2. Know not enough

It may sound like I am trying to have my cake and eat it too. Just as overreaching your knowledge can be problematic, so can be being totally oblivious to problems. Project Management text books will have you believe you need no content knowledge when managing projects. While that can be true, it can only succeed when you have able technical expertise on tap. That is not always available unless the project is of a certain size. The best way to build credibility with your team is to demonstrate you know what success looks like. You can only do that with some content background or the help of a very able lieutenant.

3. Project going too well

Things going too well early in a project is sometimes is just about the worst thing that can happen. It may sound counter intuitive. I have too many occasions where Project Managers get lazy and forget to pay attention to the important things – recording decisions, deviations from scope, paying attention to risks etc. Projects are risky endeavours. Experience tells us that not everything will go to plan during the project. If you have grown lazy with a good start, you can be guaranteed difficulty ahead when the worm turns. When Fred Brooks Jr, the father of IBM 360 was asked how one of his projects got to be twelve months late he responded … one day at a time.

4. Becoming rigid

There is a tendency sometimes to manage by actions rather than outcomes. Our goal is not to deliver the actions in the plan, but the outcome in the business case. Project plans must be living plans. There will often be the need to adjust course to get the best outcome. Sticking to prearranged plans will give you a great Gantt chart with beautiful baselines. Sometimes you can deliver to exact plans and deliver no benefits to your customer. Your plan must have some slack, so as to not fall over at the first risk. Allow yourself the flexibility of not using 100% allocation. Expect some sickness, administrative times, training needs for project team members. Avoid having to hand a change notice every day. Project Managers must understand the difference between being in the right and getting the right outcome.

5. Spreading chaos

There will always be an element of pressure on the Project Manager. We get paid to navigate the team through uncertainties. Sometimes progress is not what we hope for. From time to time we face unrealistic expectations from our own management or customers. There are various ways to handle that pressure. The one thing you must avoid is spreading that feeling of pressure to the project team. Even in most difficult cases if shield your team from some of the external pressures you have a reasonable chance to salvage something out of the situation. If you let your pressures on to your team, chaos will ensue.

I’m sure there are many other ways we can compromise a project. I would be keen to hear your thoughts.

Image Credit: http://www.techweekeurope.co.uk

Is ‘No Estimates’ for real?


No Estimates is a concept that I had not come across until very recently. The basic premise of No Estimates is there is significant inaccuracy in software development estimates. Even when you spend a lot of time estimating, it is still not necessarily accurate enough to give you an exact picture. Therefore, the time spent estimating does not give you a reward for that effort. Proponents of No Estimates argue you may as well spend that time and effort into understanding what the most important feature is to the user and concentrate on getting that delivered well. Once delivered, you concentrate on the next most import feature and so on.

Is No Estimation for real

When I first read about it, my initial reaction was it was like throwing the baby out with the bath water. Just because we are not as accurate at estimating simply giving it up seemed like lunacy. On reflection however, I can see it being useful for in-house teams that are supporting a business application. There the organisation has already seen value in continuous improvement and has accepted the software developers as part of the package to deliver the business outcome. You can concentrate on small measurable improvements to the application as directed by business. The users in this case are well versed with the application and are able to explain the desired improvement. Interestingly enough, in my experience this type of development is comparatively easier to estimate than others.

I also had a thought that product development teams may be able to use this in some manner. The rationale was they have quite a bit of control in terms of what they can cut out of scope if something turns out to be more difficult than initially perceived. However, the tradeoffs they make are not necessarily linear. There is usually not comparison that you can unilaterally say is feature A versus feature B. Feature A may very well be more important, only if it is likely to  be no more than 20% more in cost. No Estimates as a concept is not well geared to help in this scenario.

Even in scenarios where No Estimate is a reasonable course, I see significant risk of what I call ‘design blinkers’ – only taking into account the immediate requirement(s), rather than an overall view to limit rework. Design blinkers happen in all form of software development. This is because you can only design for your known scope. By limiting your thinking horizon to the next most important feature, you are in effect likely to encourage less holistic design.

From the reading I’ve done so far, it appears there is a level of misunderstanding in what estimates are used for in projects. There are no perfect estimates – projects are by nature risky. You can only ever be expected to deliver estimates with complete accuracy early on. They should get progressively accurate as you go through the various phases of the project. Initial estimates to judge whether the client has the cost appetiate to even embark on the journey, then further refining to understand whether your organisation can execute the project safely with a level of profit. These estimates will be less accurate than your feature level estimates, that you will be building up when the project goes into execution. In most cases you use multiple methods of estimating than simply a combination of all the features – previous track record, comparative scale with other similar projects and some level of feature based estimation.

In my view there will be very few situations where you can get away with doing no estimates and be able to make the decisions you or your customer needs to make. The answer is not to avoid estimating, but estimate at the level of accuracy that is required to make the decisions. Never estimate $X or hours Y. Always clearly state estimates with their level of accuracy i.e., $A to B or hours Y to Z.

Image Credit: Dilbert (Scott Adams)

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 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
%d bloggers like this: