Getting to the Bottom of Project Troubles
Getting to the Bottom of Project Troubles
It's amazing how many projects, already in a hole, keep sinking deeper. When team members and staff don't have the insight or objectivity to turn things around, an independent consultant can help...or not. In this week's column, a leading industry consultant gives you "the straight dope" on what to watch out for.
Have you ever said to yourself, "I'm in a hole and I can't get out"? It's amazing to me how many projects, in a hole already, keep sinking deeper. Is it because the only tool available is a shovel? Sometimes it's helpful if someone who is not in the hole with you gives you a hand. Can a project review by an independent consultant help? That depends.
You say you've had some awful experiences with consultants brought in to review your project? I believe you. Here are four factors that will help make sure your independent project review pays off.
The Consultant's Independence from Solutions
Effective review of a project depends on the consultant's independence from possible solutions she might recommend. For instance, if you hire a consultant who is in the rope business, she will most likely recommend throwing you a rope. If she is in the business of providing programmers, then she'll recommend more programmers. Ideally, if you select a consultant who is in the business of recommending solutions but does not make a living from delivering the recommended solutions, then you will get an objective project review and helpful recommendations. This type of consultant will provide information about how your project got into its hole and useful recommendations for how to get out and stay out.
The Consultant's Experience (and Fortitude)
A consultant's experience with recognizing what contributes to software project successes and failures is key to a successful review. A project's problems are often presented as strictly technical in nature or the fault of the technologists. But in my technical, management, and consulting experience, there are many factors in addition to technical ones that contribute. Projects are complex human systems in themselves. They involve business needs, technologies, processes, and people in a unique combination that is influenced by a company's culture, environment, and business objectives. Projects require executive sponsorship, project management, business-functional and work-process design expertise, technologies, infrastructure, and most of all, people. Project troubles typically involve all of these areas interacting with one another. And when executive sponsorship and management issues are strong contributors to the problem, the people down in the hole are reluctant to talk about them. If you're going to hire a consultant, be sure she has the courage to identify and address these issues with the executives who hired her.
The Client's Willingness to Look in the Mirror
The effectiveness of a review depends heavily on the organization's willingness to face its contribution to the project's trouble. No matter what the consultant recommends, if the organization wants to keep its head down in the hole, it will. If your organization is not ready to face its own contributions to the problem, then no amount of consulting will fix the problem.
People's Willingness to Disclose
Project members' willingness to tell the consultant about their issues definitely affects the quality of the review. The consultant has no way of living through the project the way they have lived it. If the consultant is worth her salt, she will advise the client about matters of safety needed for people to speak freely. If people believe the review is about "finding and punishing the guilty," they will not express their thoughts, opinions, and concerns. This in itself might be the biggest problem the project has. If so, the consultant should be able to figure this out. Consultants are often listened to more than internal project staff because they are from outside the organization. They are being paid to look with different eyes. They are being paid to speak the unspeakable. If people view the consultant as the enemy rather than a helpful ally, they may withhold valuable information and perspective. Later, the same people may complain about the consultant who didn't really get to the bottom of their troubles. But don't expect the consultant to simply be your mouthpiece or management's patsy. The consultant adds value by applying her own experience and skill to your situation.
Sure, there are inexperienced, biased, and maybe even spineless consultants. But those who are not can be the objective eyes you need. And if the people on your project, including your executives, are willing to act on solid recommendations, you just might lift your project out of its hole.



Comments
#1 Submitted by Nancy Kramer on Tue, 09/11/2001 - 11:47am.
I'm now on my second job as a consultant. When I took my first job, I looked across the table to my client and I told him He was paying me to tell him the truth. And if he didn't want to hear the truth, he wasn't going to gedt his money's worth. This really benefited us both. He appreciated my candor and I had the ear of management all the way up to the senior level. I also had the trust of the people on the floor. We were able to accomplish a lot in a very short period of time. I'm not sure if my policy of being forthright will always benefit me. But I don't know of any other way to offer my services.
#2 Submitted by William Trest on Wed, 06/20/2001 - 12:29pm.
My experience is that Consultants have not cornered the market as the only source of "inexperienced, biased, and spineless" people. Hiring a consultant to review a project; before, during or after the fact that troubles exist, seems both a slap in the face and denies that software project troubles really do happen every day. It happens within the software project's own process and plan, operated by project personnel. Perhaps projects misuse their technical staff, where products may be well-tested, but processes and process yields were ignored. Watts Humphrey was correct; projects will have a process, characterized somewhere between chaos and optimizing, and a product of some sorts, but if you can only control one part of the developmental environment, it must be process maturity and predictability.
#3 Submitted by Eileen Strider on Sat, 04/21/2001 - 12:00pm.
It's not too much intellectual capital for me to give away but it would have been too many words to fit the column's word limit. Martin's list of areas he would review have a lot of similarity to the kinds of things I include in reviews. Here's an overview of areas I often include in a review.Generally, I look at four major areas in a review.Executive Sponsorship: Is the sponsor personally giving the project the time, resources attention it needs to succeed (too much or too little)? Are the sponsor's business objectives clearly defined? Will the project strategy lead to business objectives being met? etc.2. Business Functionality: Are the business requirements defined including both functional and data needs? How are the users of the system involved with the project to ensure the system will meet the requirements? etc.3. Management Capability: Does the people in project leadership roles have the skills, experience and support to lead the project to a successful conclusion? How is the project progressing versus it's plan? Are there artifacts observable that support the progress reported? etc.Technical Capability: Do the people working on the project have the technical skills, experience, tools? Is the necessary development and production infrastructure in place? etc.When a review is requested, it's typically because the the requester has some worries or concerns about the project. I ask the requester what questions he would like the review to answer and then I focus the review work to be able to answer the questions.If anyone would like to hear more about this, please send me an email. I'd be happy to continue this discussion... Eileen
#4 Submitted by NikkiBianco on Thu, 04/19/2001 - 12:23pm.
This sounds more like a 'hire me as a consultant' ad than useful information, however the high level stuff is pretty good. Management commitment, gutsy consultant (internal or external to the organization/company), and willingness to accept fault and change. I was hoping to see something more in the 'warning signs' of project doom than what I got.
#5 Submitted by Jon Hagar on Thu, 04/19/2001 - 11:53am.
Setting the title aside, the article is correct in pointing out the issues with using outside reivewers or consultants. These people are not magic and projects must have realistic expectations about getting them. I have been both "reviewed" and done the reviewing. Reviews are not just for troubled projects. Good project can use the independence to see how to be better, but the concepts the article outlines must be considered if a project wants to benefit.
#6 Submitted by Chris DeNardis on Mon, 04/16/2001 - 9:57am.
I was a bit confused by the title after I read the article - maybe the title should have been To hire a consultant or not to hire a consultant - to look into the project troubles?However, I believe the team (both developers and testers) must be willing to put down their guns, be assertive, and be open of why the project has failed. But why stop there? Why not discuss what went well, and continue to enhance on it? A good retrospectives on a project would also identify those changes.Sometimes I feel a consultant will tell the group what they already know, but have failed to listen. Therefore, I believe we as project leaders may just need to listen a little more.
#7 Submitted by Yogita Sahoo on Tue, 04/17/2001 - 11:08am.
I enjoyed the article thoroughly, though I never got a chance to work with independent consultants (The projects in my company never fell that deep in to a hole). The article would have been more useful if Ms. Strider had taken these scenarios (mentioned below) and shown the consultant's role in each of these.Consultants are hired when the project is sinking gradually, and they come as a lifesaver. They are also hired when the project is gone out of hand, to find out what went wrong with whom and how can things improve for future projects.I would have loved to know how a consultant fits into the picture as a solution provider and a defect analyser, seperately.
#8 Submitted by Martin Kalugin on Tue, 04/17/2001 - 9:09am.
I was disappointed by this article. I guess it's too much intellectual capital to give away a methodic approach to troubleshooting a failing project. So, some of the steps I would probably follow are:-1, Is the project supposed to be following a specific development process (RAD, RUP, Waterfall)?2, If so, what artifacts have been produced versus what should have been produced?3, Is the project managed by a project manager? If so, where are the relevant PM artifacts? (Risks & issues list, assumptions, project plans, change control forms, etc...) Are the risks and issues being addressed actively?4, Have the requirements been documented and reviewed with the client?Anyone care to chip in with some other areas that they would look at in a failing project?