Turnaround specialist Todd Williams has worked with many companies rescuing failing projects. In his new book, Rescue the Problem Project: A Complete Guide to Identifying, Preventing, and Recovering from Project Failure he reveals an in-depth, start-to-finish process that will enable you to finish the project successfully. In this interview, he discusses the biggest mistakes made when starting large projects, and how to complete a project on schedule that meets project specifications.
Commitmentnow.com: What do you see as the biggest mistakes most people make when embarking on a large project?
Todd C. Williams, PMP: The biggest is that people do not comprehend the complexity of the project, but think they do. If you think about the process, it is broken from the start. Someone in the organization comes up with an idea an then they immediately start trying to figure out solutions. They completely skip over doing enough requirements to define the complexity.
When people try to point the potential issues from overlooked complexity, they are labeled a pessimists and non-team players. This results in management making decisions using only a small part of the data they need.
The second biggest problem would be using the wrong methodology. There are two common sources for this—management’s requirement to use an in-house methodology and the lack of visibility into the complexity of the project, which I just mentioned.
If you know that a project is complex or poorly understood, you can apply different methodologies to improve the chances for success.
Say, for instance, that you are facing taking on large, complex project. Figure out ways to break it down into smaller components for delivery. Creating three phases for a $10-million project, effectively makes it three $3.3-million dollar projects, with one-third the staff. The three sequential projects are much easier to manage.
Commitmentnow.com: What are five things that can be done to ensure that a project is completed on schedule, within budget, and in full accordance with project specifications?
Todd: Honestly, sometimes that is impossible. We all know about the triple constraints and the customer cannot define the features, the cost, and the timeline. You need to have a flexible approach that will handle the changes that arise. That said, here is a guideline:
a. Know your degree of certainty on what you are building.
b. Use the right methodology to build it.
c. Focus more on leading people and less on managing the project.
d. Daily talk to the core team and a random set of stakeholders.
e. Manage change; do not try to control it.
Remember though, just because you have hit the scope, schedule and budget, does not mean that you are going to have a successful project. I have seen plenty of projects complete meeting those goals and everyone seems happy.
Then they find out that no one uses what they produced. The product has no value. Many people blame the customer for this; however, there is plenty of blame to be held by the project team. They should be insuring the real end users are involved and the methodology they are using confirms value throughout the project. This is most critical in the early stages, before much money is spent.
Commitmentnow.com: How can a manager break down a project into defined and detailed steps that result in a working goal breakdown structure?
Todd: Be careful, this is quite often a mistake. Trying to define too much detail can get you into trouble. That is why knowing the “certainty on what you are building” is more important than knowing what you are going to build.
I have seen multiple projects that have volumes of documentation describing what is going to build and it is all wrong. People are building and running the project with those goals in mind and headed the wrong direction. Yes, you need to have some detail, but that is not the goal of the project.
Commitmentnow.com: What you are saying then is that dealing with a client who is unsure of what they want is not as big as an issue as most people claim--how then can the project be planned correctly and stay on the right track?
Todd: To a degree, yes, that is what I am saying. There is little to save you from the customer that is clueless and does not want to hear reality. However, you can always refuse to do the work. That will not help them, but it will reduce your stress, the headaches, and bruises to your reputation.
If you must do the work, your best defense is change management. You obviously cannot control change in this situation—there is nothing to control. Instead you have the job of taking the customer down the path of discovery. Take the customer’s ideas and materialize them in a way that they can see her flaws.
Commitmentnow.com: Why do so many projects go way over budget? What can be done to avoid this?
Todd: There are two primary reasons that projects exceed their budget. The first is the customers knows what they want, not what they need. If this goes unchecked for long the project is building the wrong product. That costs a lot. You need to tear down what you just built and rebuild it to what they need.
The second reason is that the project manager does not manage scope. Scope creep is not just a customer issue. There are many times that the project team adds frills and glitter. This, especially in IT projects, is easy to do if the project manager is not paying attention to the team and spending too much time focusing on pleasing her superiors.
The project manager needs to stay engaged with the project team. She needs to know what everyone is doing and why.
Commitmentnow.com: Why do many projects fail to meet their deadlines--and what can be done in the initial planning stages to prevent this kind of failure?
Todd: Key in your statement is the term “initial planning.” Classically, projects start when the customer provides a Request For Proposal (RFP), or the like, to a supplier. This is too late to get a delivery team involved in the concept of the project. By this time, the expectations have been set. Worse, there are multiple sets of expectations inside the customer’s group. The lack of alignment is what kills the project—It kills it long before it even starts.
The project’s concept has been around long before the RFP—maybe six weeks, six months, or even six years. Over that time various factions inside the customer have developed ideas about what this “thing” should be and these opinions are quite diverse. Now, a delivery team gets thrown into the mix. This brings the reality of what really can be done and the shape of what is being built morphs even more.
To combat this you need to get involved much earlier with the customer. That is the Guidance Team that I talk about in Chapter 17 of my book Rescue the Problem Project. Get people involved with the customer early—the people that know how to build what is being looking for and who can help track the changes that the concept goes through.
The guidance team can carry that thought through from the real project inception—with the customer—through to the project teams that will build it.
Commitmentnow.com: What elements do the most successful projects have?
Todd: I do not know of a successful project that did not have an absolutely superb team. Teams are crucial. When I am doing a project recovery, this is job number one. It is even more important than figuring out what is supposed to be built.
A good team can figure out what to build; well defined scope does not build a team. There are four principles that a project manager should live by:
1) The team knows how to build the product and what is failing in the project. It is paramount that project manager builds a strong team with ALL of the stakeholders.
2) Strong team can overpower even poor management. There are many deficiencies in organizations that can make a project red. A strong team can overcome those. Even if the problem is indecisive or otherwise ineffective management.
3) Stay involved with the team. Too many project managers feel they should sit outside the team and direct it in an imperious manner. This is a recipe for disaster. Stay involved with the team. Do daily checks with a random set of individual contributors. Do this to a point that people are comfortable with you always being within ear shot. You will hear more about how the project is running.
4) Data is your friend. The Project manager has to know everything about the project. The good, the bad, and the need for contingency. Staying peers with the team helps get this information. With a complete data set, you always have the correct answer, even if your answer is “I do not know.” You know what you know.
Commitmentnow.com: When leading a project team, what helps to keep everyone getting along and working together smoothly?
Todd: Leadership and management. You have to create a vision, build a team aligned to that vision, and allow people to be independent and excel at what they do. This requires a lot of classical management—talking to your team, making sure they are still on the right path, solving inter-personal issues, and so on.
As the project manager you must lead by example and have superlative communication with all the stakeholders. If people refuse to be part of the team, you must replace them. It is painful to do this, but that is what leaders have to do and it gains respect from everyone.
Commitmentnow.com: What information should be collected when evaluating the progress of a project?
Todd: It depends on the project. If you are using an agile methodology, watch the burn-down list. However, make sure that you are getting to something to deploy quick, too. If you fail to get usable product in front of the customer, you will not know if you are building the right product. Remember that value comment? Having the customer use the product is the best way to track value.
If you are not using agile, I have to assume the project is well defined (if it si not you should be using agile). With that you should easily be able to develop frequent milestones to judge the progress. Miss many milestones and you are in trouble. The first question you need to ask is whether your project is well understood or whether people just thought they knew what they knew what the project was supposed to do.
Commitmentnow.com: Finally, how did you become a project expert and what habits and qualities do you feel are needed to successfully manage and execute projects?
Todd: As I said in the introduction to the book, I did not aspire to this job, it found me. My biggest attribute is that I am analytical, objective and can make decisions. Those are traits conspicuously absent from much of today’s business world.
People are failure averse. If you make a lot of decisions you are going to be wrong now and then. The job is to minimize the failures with contingency plans. You also need to be thick skinned. When you are making decisions that others shy away from, it is because there is not a clear consensus in the team—half the people are going to dislike your decision. Rest assured, in the net decision it will be a different half.
Thank you for your questions and time to talk with you and your audience. I am honored that you asked for the interview. If there are any questions please do not hesitate to get hold of me.
To purchase Rescue the Problem Project click here.
About the Author: For twenty-five years Presidents, Vice Presidents, and C-Level executives of manufacturing and service companies have asked Mr. Todd Williams to help them build leading-edge systems, improve organizational efficiency, and turn-around troubled projects.
From this experience, he has developed methods to streamline organizations, recover red projects and help prevent recurring failures.
In his first book, Rescue the Problem Project: A Complete Guide to Identifying, Preventing, and Recovering from Project Failure (AMACOM Books), he defines a project audit and recovery process that rescues failing projects while focusing on root cause correction and prevention.
His experience covers many domains inside manufacturing and service industries. Experience is drawn from working on internal and third-party projects, including integration of manufacturing systems, equipment integration, web-based collaboration tools, thick clients with automated internet update, and large-scale business systems integration.
His cultural experience includes the Pacific Rim, Middle East and North America, coordinating teams dispersed in as many as five countries, three continents and countless time zones.
As President of eCameron, Inc., located outside Portland, Oregon, he is considered an expert in rescuing projects and preventing their failure.
He maintains a blog at http://ecaminc.com/index.php/blog that has been quoted on ZDNet, The Center for CIO Leadership, CIO Essentials, IT Business Edge, and Project Managers Planet.