Probably you have, because this sort of thing happens all the time, in all types of projects and organizations. There are any number of reasons why a project might end in disappointment, and some of them are beyond your control — for instance, customer tastes may shift away from your product, rapidly evolving technology may leave you behind, or even random events like the weather may work against you.
However, one of the most common reasons for project failure is fully under managerial control, and is also quite easy to fix. Many projects fail simply because participants perceive their responsibility as “delivering a solution” instead of “solving the problem.” It’s a fine distinction, but a critical one.
Most business projects go through a series of stages. First an opportunity or problem is identified, and then, frequently, there is a phase of evaluating potential solutions and choosing the best one. At these stages of a project, the problem tends to be clear in everyone’s mind, and everybody is focused on solving it.
However, when the project reaches the implementation stages, participants have a natural tendency to shift their attention towards enacting the chosen solution. The perceived goal becomes implementation of a specific new system or product, on time and within budget. Big-picture awareness of solving the original problem or exploiting the original opportunity recedes.
This tendency is exacerbated by two things. One is the habit of managing to the internal metrics and deliverables of the project, rather than to its goal. Managers may overemphasize achieving intermediate milestones. When an issue emerges — for example, an assumption in the project charter turns out to have been inaccurate — there can be pressure to “just power through it” rather than disrupt the project timeline or budget. Mid-stream adjustments, which would keep the project on track to “solve the problem,” go unmade because they would cause a delay or additional expense.
I saw an example of this at a firm which was building a new module into their accounting system. During the implementation, it was discovered that the original specification was missing some important use cases, and therefore the module was not designed to do everything that the accounting department needed.
The project manager argued that adding in the missing features would be unacceptable “scope creep,” because they weren’t in the original spec. Rather than extend the project timeline in order to build in the missing components, the team delivered it as spec’d — on time, on budget, and incomplete for the needs of the users. The accountants were left to rely on inefficient spreadsheet workarounds, because the delivered solution didn’t solve the problems it was supposed to solve. Eventually, although the project was done “on time and on budget,” the module was abandoned.
The other exacerbating factor is the diffusion of responsibility among multiple individuals. Especially as organizations grow, there can be several people sharing ownership of a project:
- A project “sponsor,” whose department funds or benefits from the project, but often doesn’t work on its implementation
- A project “champion,” who advocates for the project on behalf of the sponsor
- A project “manager,” whose handles the administrative side: meetings, reports, Gantt charts
- Project “resources,” who execute the implementation work
- Project “stakeholders,” who are affected by the project and are informed or consulted about it
Depending on the organization, there may also be other fun titles (Project Director, Controller, Ninja, etc.) or a distinction between people who are “accountable” for the project (answerable to senior management) versus those who are “responsible” for it (doing the implementation work.) But what is often missing from all this is a single person responsible for making sure that the problem gets solved.
At another company I’ve worked with, the sales team needed the CRM system modified to help them sell to a new category of customer. A sales manager was the project sponsor, and saw her role as funding & backing the project. An IT person was the project manager, and saw his role as delivering a specified list of software and data updates. Each person fulfilled their perceived role, but in the end, the sales people didn’t embrace or use the new system. The project consumed resources, and the people involved declared victory, but no value was created.
The sales team felt that IT hadn’t delivered “a user-friendly solution,” while the IT team felt that they delivered what was specified and it’s not their fault if the users don’t adopt it. In fact, both sides are right, and the real issue is that both sides only perceived a narrow mandate to deliver part of the solution, and nobody had broad responsibility for solving the problem — that is, for enabling the sales team to win those new customers. That responsible person could have come from either side, IT or sales, and could have taken steps to ensure that the project achieved its goal. Instead, the project wasted time and resources on an outcome that nobody was happy with.
How can you avoid these issues in your own organization? Here are three tips for making sure your team solves problems instead of merely delivering solutions:
Document the problem or opportunity. State it in the project charter, scope, and other documents. Restate it in every meeting and memo. Be sure to define success — what does “solved” mean? — in a measurable way that everyone can see. Make clear to everyone, throughout the project, that the goal is to solve that problem, and not merely to generate work output or hit milestones. And when issues arise, ensure that they are resolved in a way which serves that goal, instead of only serving the internal project metrics such as timelines and budgets.
One owner. One person should have single, ultimate accountability for solving the problem, and as Peter Bregman has written in the Harvard Business Review, “Accountability is about delivering on a commitment. It’s responsibility to an outcome, not just a set of tasks.” To the extent that this person’s performance evaluation is based on the project, it should be measured by this standard. Likewise, the individual members of the project team should be evaluated in part based on how well they contributed to a successful solution, rather than strictly on hitting deadlines, budgets, and intermediate milestones.
Ask, “Are we solving it?” As a project runs its course, people are naturally eager to keep it on schedule, get it done, and then move on to other things. It’s worth stopping occasionally to ask explicitly, “Are we solving the problem?”, and even to delay the project closure if the answer is not a strong “yes.” It can be painful to acknowledge shortcomings and spend more time & money extending the life of a project, especially when you thought you’d be done by now. But the truth is, even if the project is “supposed to be done now,” there will never be an easier time to keep going until you get it right: The work is still fresh in peoples’ minds; the vendors and consultants are still available; project documents haven’t yet been lost or discarded; users or customers aren’t accustomed to the new product yet and will accept further changes readily. If you don’t fix the issues now, it will only be harder and costlier to fix them later.
By applying these tips, managers can ensure that their organizations’ projects are oriented towards truly solving a problem, rather than delivering a costly solution which doesn’t work.
Source: Medium
