Project Killers: An Ode to Death by Documentation

project_killers

The story below illustrates one of the most common project killers – documentation for the sake of documenting, performed at the expense of making true progress towards project completion.

This is the story of one Guru Kumar, a brightly shining Acme PMO star.

Guru was an expert on SDLC, RTM, UML, and Rational Technology

Microsoft Office, and Visio, and Plan, were as familiar to Guru as his right hand

So as soon as the project began, everyone knew Guru would be the ‘man’

First he redid the requirements list, just in case an item was missed

He re-estimated the tasks with pep, to ensure the Plan would have each step

To prevent any false move, every document would be doubly approved

And Guru proved that he could wait, even when the approvers missed the approval date

Days turned to weeks with no code begun, but the documents piled up one by one

Requirements Traceability in 2 different views, Gap Analysis for every screen to be used

Scenarios, Use Cases, Success Metrics and more, each crafted with greater care than the one before

Next came the RAID, test cases, and executive summaries too, each with redundancy about what the project would do

The project team once eager to get started, became very quickly broken hearted

The project with such potential for return, was just about certain to crash and burn

Some dared to ask wouldn’t it be smarter, to start instead with a Project Charter?

That document defines the scope and rules, defines what will be done and what will be the tools

And surely, wasn’t enough about the project known, that the first seeds of a Project Plan could have been sown?

That the other docs would be needed there was no doubt, but would it have been possible to spread them out?

At last Guru felt that the documents were created, but to his dismay found that the team hadn’t waited

New priorities in the Acme business had been found, and some from the team were no longer around

The budget for the project was almost all spent, the investigation begun into where the money went

Guru Kumar found to his dismay that Project Killers are always eager to hold sway

Guru learned that no matter how hard he was working, Death by Documentation is always lurking

He found that the method that works the best, the method that has been tried and passed the test

Is to keep in mind that the project objective is best achieved when you are selective

About the documents you think you need, and discard the rest like a noxious weed

Only create them when needed and ensure that they are living as long as the project endures

Cry not for Guru, his bridge wasn’t burned; Acme realized the lessons he had learned

The Acme PMO once again has a brightest star, the much wiser, and less busy, Guru Kumar.

Jim Lindenfeld, Principal Consultant

Jim Lindenfeld, Principal Consultant

This blog was written by Jim Lindenfeld, who has been actively involved in customer relationship management during his entire professional career.  He is a certified sales and sales management trainer.  He has been involved in the implementation of CRM systems since 1987 and is currently a principal consultant in our CRM practice.

Illustration created and provided by Jonathan Pike, eVerge Group IT Specialist.

 

 

Project Killers: The Path to On Time, On Budget and In Scope

project_killersA new IT project has been initiated. The CRM system is going to be upgraded and integrated. Visions of new capabilities and increased profits fill the waking hours of the CEO and the VP of Sales. By day the CIO appears to share in that dream, but while everyone else sleeps, the CIO is visited by the nightmares of projects from the past where deadlines were missed, cost overruns were the norm, and a severe reduction in project scope was inevitable. Sometimes, when the nightmares are the scariest, the CIO even allows his psyche to relive the horrors of several projects that were complete failures. Meanwhile the IT Project Management Office, the Business Analysts, the System Architects, and the Developers stare in disbelief at the list of approved requirements and the approved budget and timeline for the project and sadly shake their heads. “Do they even have a window in that ivory tower?” they mutter. To all but the most uninitiated, the project is dead on arrival. How did this happen, how can it be prevented in the future?

Successful IT projects can no longer be optional or left to chance. Due to the inseparable integration of IT and the rest of the business, the success of IT at any business is the success of the business. We are taking a fun and somewhat irreverent look during the next few postings at the Project Killers in our midst and how the white knights in business and IT can vanquish them in as part of a successful project.   These Project Killers are usually easy and inexpensive to avoid, yet most of us have fallen victim to one or more of them:

  1. Dead on Arrival (a.k.a. DOA) – A project without the proper estimations for time and resources somehow is initiated
  2. Death by Documentation (a.k.a. strangled in red tape) – A great deal of time and effort goes into plans, requirement documents, and design documents with no real benefit to the project
  3. Death by Indecision (a.k.a. analysis paralysis in its milder forms) – Key project decisions are delayed or avoided altogether
  4. Death in Unchartered Lands (a.k.a. scope creep) – The participants, stakeholders, scope, and methods, are never agreed to formally when the project starts. If you don’t know where you’re going, most any road will take you there – but it may take a lot longer and cost a lot more!
  5. Sudden Unplanned Death (a.k.a. running into a dead end) – risks are not properly identified and mitigated
  6. Death by Starvation (a.k.a. bottlenecks) – resources are not properly identified and allocated

Many projects are Dead On Arrival – DOA.   Often this happens because the actual amount that would have to be invested to achieve the expected results is significant enough to reduce the return on investment to a level that is no longer acceptable. So instead of a fair estimate for a reasonable gain in productivity/reduction in cost, companies and their suppliers “tweak” the estimates to be more favorable – the delivered system is estimated to bring more benefit, the investment in licensing and maintenance costs is underestimated, the resources required – both internal and external to the company – are estimated at reduced levels, and all of that will happen during an accelerated time line! Perhaps this has happened to you once or twice?   Perhaps you have even had the project approved based on those over and under estimations to find that you can’t even get the project successfully started – in other words, the project is DOA.

If your corporate culture is geared to delivering a number of DOA projects, you can break the cycle and get back to successful IT projects that deliver fully on their promised benefits, on time, and within budget. Here are the simple and inexpensive steps to avoid a DOA project.

Good, Fast, Cheap – Pick any 2: This is a great way to prevent DOA projects. First, define ‘Good’ – what is the real problem that you are trying to solve – increased productivity, cost avoidance, customer satisfaction, employee morale, competitive advantage, new legislation, etc.? How much is solving that problem worth to your company – try hard to put it into dollars and cents! Next, define ‘Fast’ – is there an event on the horizon that dictates the release date? You should consider product releases, fiscal years, acquisitions, competitive activity, corporate recognition programs and national meetings, and meeting legal requirements among other time related drivers. Finally, define ‘Cheap’ – based on preliminary estimates what is the maximum amount of money you are willing and able to invest in the system? When putting together the project, simply remember that you will always be able to have only 2 out of Good, Fast, and Cheap. If you want a complete, high quality solution (Good) and you need it quickly (Fast) it will NOT be inexpensive (Cheap). If you want a high quality solution (Good) and you want it to be inexpensive (Cheap) it will NOT be Fast! Finally, if you want it Fast and Cheap, it will NOT be Good!

In today’s IT environment where the pace of innovation is constantly accelerating, few if any businesses can afford to choose Good and Cheap at the expense of Fast – the project delivery will be so far in the future that the envisioned benefit may not be realized (and we have seen this happen!). So that leaves just 2 choices – Good and Fast; and Cheap and Fast. That is why it is so important to carefully define ‘Good’ and ‘Cheap’ initially. If your definition of Cheap is significantly fewer dollars than Good (project has a high ROI) then pick Good and Fast and recognize that your investment may be higher than estimated. If your definition of Good and Cheap are closer together, consider breaking the project into smaller, quicker wins and choose Cheap and Fast to keep to budget with a partial solution. Finally, if your definition of Good is less than your definition of Cheap realize that the ROI for the project will most likely be break even or negative and only proceed where required by legal or business conditions and choose Good and Fast since it is likely that you are proceeding only in the cases where you need a quality, complete solution in a hurry. In this scenario, expect to invest more than you initially thought you would.

Remember “Good, Fast, Cheap pick any 2” and your projects will be vital and alive at inception. Avoiding the other Project Killers can be just as easy. We will discuss the process over the next few postings to this blog.

Jim Lindenfeld, Principal Consultant

Jim Lindenfeld, Principal Consultant

This blog was written by Jim Lindenfeld, who has been actively involved in customer relationship management during his entire professional career.  He is a certified sales and sales management trainer.  He has been involved in the implementation of CRM systems since 1987 and is currently a principal consultant in our CRM practice.