We all seem to know that throwing people at a late project may only make the project later.  Yet, we all too often still do it for a variety of reasons including as a way to manage risk in a project.  Having your best people ready to jump in and solve problems appears to be a smart strategy, but is it really?

We had another great discussion on risk centered on the notion that there was no way to eliminate problems without having infinite resources.  Of course, project risk management is not about eliminating problems, but about minimizing their impact to the project.  However, I’ve seen repeated attempts at risk management by throwing resources at the problems.  In over 30 years, I’ve never seen this work except in some very well organized projects (yes, it can work well if we prepare for it).

On one project, where I was the new guy and generally in observation mode, the primary risk management approach to delivering a new software release to a customer was to bring the whole development team with us.  The notion here was that if everyone was on site any problems could be quickly fixed.

The delivery was a disaster.  In fact we had a history of delivery disasters to this same company.  At the time of this delivery, this customer was not paying for services as our past deliveries had been so bad that we had agreed the customer wouldn’t pay us until we were able to make good deliveries.  However, having everyone on site did not address the fundamental problem that the delivery was of poor quality and not well planned.

On our next software delivery to this same customer I was now the project manager.  Instead of bringing the whole team on site, I essentially had everyone review the project delivery plan in advance and in detail.  Actually, I had them review it over and over again, which started to annoy everyone greatly.

On the day of delivery, and I admit that only a week before I was about ready to push out the delivery date,  I showed up at the customer site — alone.  It was just me.  The customer’s IT Director, not realizing I was alone, told me that I could get started and to go and assemble my team.   I told him that it was only me but that the rest of the team was on call back at the office on the other side of the country but with remote access to the customer’s system.  He looked pretty dubious given our past track record.

We did indeed have multiple problems during the delivery.  However, as it turned out our preparations were rock solid and the problems we encountered were almost all due to the customer.  This almost became a problem by itself.  On several occasions I found myself saying “I’ll talk with the team on this problem” then went off and had some coffee.  I then came back and told the customer “here, try it again – just as it is written, and it should work now.”  The customer had been so use to us making mistakes that their own attention to detail was poor.  It seemed that they were not worried about making mistakes, because in the past our instructions and software were so error prone that anything they followed didn’t work anyhow.  This time, the only real problems we encountered were with the customer and that was probably our fault too.

The delivery worked the first time.  This had never happened before.  The customer ultimately acknowledged the success and began to pay their bills again.

The COO of our company demanded that every delivery in the future should work out just like this one!  She was an interesting person and liked to talk in absolutes and numbers that were either 0% or 100% (for more see Being Slightly Out Of Project Management Control Can Be A Good Thing.)

In fact, when I later took over as the director of software development for this same company, we increased our product quality such that our delivery teams no longer were limited to upgrading one customer every other week.  We could now upgrade several customers each week with the same staff.   I was too new to have done this by being an expert in the management of our development and delivery.  Instead, I had focused on minimizing the risk by primarily getting the project management schedule right which resulted in a substantial increase in quality.  The common belief up until that time had always been that our problems were predominately due to a lack of adequate project staffing.

Managing risk is not simply throwing resources at a problem as it occurs – though we all seem to do it at some time.  As with any problem solving, it involves understanding the root cause of the issue, and having actions and plans in place to mitigate the impact of the risk if it occurs.