One of the most entertaining performances in Quentin Tarantino’s classic film “Pulp Fiction,” was Harvey Keitel’s portrayal of “The Wolf,” who served as a highly effective and professional “clean-up guy” after Vincent Vega (played by John Travolta) made a major tactical error with his gun.
While the world of IT is much different (and, luckily, safer) than the criminal underworld portrayed by Tarantino in this film, I sometimes find that we play a similar “clean up” role with major IT projects started by previous consultants that tried to implement a customized web solution, but made their own tactical errors and veered seriously off course.
The goal of this post is not to tout how much more effective we are than other web solutions providers. There are many consulting firms that can deliver quality projects on time and on budget, and it would be disingenuous to suggest that all of our projects have been flawlessly implemented. Instead, I would like to share my insights, based upon 20+ years of managing IT projects (mainframe, client-server, and web-based), on some of the main reasons why efforts tend to go awry.
1) Poor definition of the project requirements — Both IT and business people seem to understand the need for properly defining requirements, yet it is often the main cause of why projects fall short of their purpose and go off-track. I believe the project manager/lead consultant needs to have the skill set to start with high-level goals and engage the project sponsors/subject matter experts (SMEs) to dig into the details at a level necessary for the development team to provide solutions that meet the needs of the project.
It’s also important to document what comes out of this interaction so that both the sponsors and IT team have a common document everyone can understand and use throughout the project. The project’s level of complexity should dictate the level of detail needed for the requirements/specifications to be an effective document to make the project a success. And the document should be updated throughout the project so it represents the most current version of what the sponsors want and the IT team should deliver.
2) Lack of a descriptive, usable project plan — Like the requirements, the project plan should be written to the level of detail needed for the project sponsors and IT team to understand what needs to be done, when, and by whom. It too should be a living, breathing document that is constantly evaluated and updated according to the latest requirements and information learned from the ongoing effort.
We have been asked to step in on projects that are off-course where the project plan was created at the onset of an effort and never revisited, as if its sole purpose was to provide the client with a document to reassure them that a plan would be followed, for the sake of getting the business. The plan ended up sitting on a virtual shelf somewhere and the IT team went off in their own direction, without concrete deliverables or timelines that the client could track.
The purpose of the project plan is to use it as a tool for managing the effort. It should set the expectations of the sponsors and the IT team for what remains to be accomplished to ensure the effort is on track. If it’s not used this way, it’s a sure sign that the project is headed for problems.
3) Providing solutions to the client too late in the project — It’s fine to espouse the virtues of an iterative process on a project, but it’s another thing to have the discipline to actually adhere to it. The basic tenets of our approach are “interact and iterate.” The requirements and project plan require a significant amount of interaction, while the development effort needs to break up deliverables into reasonable pieces to allow for iterations of the solution to be evaluated by the client as early as possible.
The purpose of providing solutions in smaller portions, modules, “chunks”, etc. is to mitigate the risk that the IT team has missed the mark and ensure they are in sync with the needs of the client. The only way this will be accomplished is through good initial planning and identifying which portions of the system will be delivered and when, based upon the project plan.
Over the last seven years of managing client efforts at NetLink, we have sometimes been asked to step in and play the role of “The Wolf”, e.g. “IT clean-up guys”, for projects that have gone awry. Fortunately, none of the efforts we’ve undertaken for our clients have required this form of outside intervention.
I would attribute this to the use of our project approach, the NetLink Adaptive Process™. But, more importantly, it’s the discipline to adhere to the execution of the process that determines the outcome of an IT project. And following the process for your project is much more preferable than having to call in “The Wolf” to clean it up.
Posted by: Steve Short, President, NetLink Resource Group