When given a task, project managers tend to “never say die.” Laudable though this attitude may be, it raises an important question: As project managers, how do we proceed when we question whether our latest project is feasible?
Project characteristics that commonly foster doubt include:
- Large in scale
- Complex interactions with incoming data
- Novel elements and historical constraints
- Extended development time
Since these issues resist the divide-and-conquer approach, project managers frequently have to tackle them head-on. Let’s briefly examine each of these characteristics.
Large in scale
The mere fact that the project is large isn’t the issue. The problem is that, as the size of the project increases, so does the level of difficulty in dealing with the other factors that can raise doubts about the project.
The key is not to focus your attention on each subtask. Instead, keep a to-do list that reflects the real project priorities. If you get a problem related to the project’s size or complexity, you need to act as soon as possible to limit its effects. Adopting common standards and protocols at the very start of the project is essential to minimizing such problems.
Exhibits complex interactions with incoming data
This is true of every line of code developers write. It’s what makes IT project management such a challenge.
Testing such complex interactions may prove difficult. Not only is it unlikely you’ll operate the system, but it’s also hard to test such systems until developers wire submodules together.
Contains both novel elements and historical constraints
“Impossible projects” are usually highly specialized. They’re constrained by existing designs, protocols, and practices, and you may not have a project template or reusable code.
It’s hard to define risk factors for this characteristic because they might involve novel technologies. The best approach is to plan a series of advance feasibility studies to limit the risks.
Takes a long time to develop
Team members may come and go; that’s why maintaining team concentration and morale can become one of your main tasks. This is particularly true of a project in which it becomes difficult to achieve contractual sign-offs because of niggling about important work in the final stages.
These are the project factors that will make you lose sleep. If the system is inherently tough to break down into discrete component subsystems, it can be harder than usual to stay on track. (This is yet another reason to hire developers with diverse skills, specifically with respect to their knowledge of programming languages.)
Though project managers are keen on planning in detail, they’re often hampered by unforeseen, holistic interactions. The development process isn’t linear; it’s web-like and probably more iterative than you can predict.
I don’t recommend building a simulation of the entire system because that would likely be as difficult a task as the build itself. If you can’t divide the project into manageable parts, you should at least try to identify most of the potential problems and act to limit them. One of the biggest challenges for a project of this type is envisioning the system at different scales.
Final words of advice
Refer to the specs frequently. If a project contains inherent contradictions, highlight them and request more clarification from the client. Make the areas of uncertainty clear to your development team from the outset, and consider devoting most of your effort to the early stages.
A “project impossible” requires parallel validation and verification processes. Remember to keep asking yourself: “Are we building the right thing?” and “Are we building the thing right?”