News
As projects ramp up again, remember that ideas don't transport well
01 Mar 2010
Source: Computerworld
By Paul Glen
With the economy picking up, enterprises are cautiously starting new projects. Managers are tiptoeing over to their backlogged to-do lists and gingerly picking out projects that can no longer be delayed. That's good news for all of us.
We like building and fixing things. We like progress. And we like having jobs and paying the rent.
Understandably, managers are taking extra precautions to make sure that these first new investment projects go well; they don't want to start with a bad project that kills what little momentum they have. You can't fault them for doing everything they can to ensure success. It's just that some perceived guarantors of success are no such thing.
What I've especially noticed lately is managers trying to preclude failure through their project staffing choices. Many are assigning people to projects, or even hiring new people, because they have successfully done the exact same sort of project before. Naturally, it's a good idea to hire competent and experienced people. But the assumption that previous success guarantees future success is flawed.
At the heart of this fallacy is the fact that successful people rarely know why they were successful. In itself, that isn't a problem. The trouble is that they think they know why they were successful. They believe that their previous choices all must have been correct and will serve them well when they're confronted with a similar project. They're certain that the obstacles they overcame before can be avoided entirely or resolved in ways that are similar to what worked in the past.
The truth is that it is very hard to really understand the conditions that made certain choices work and others not. It is far too easy to extrapolate a single data point into a rule.
This leads to the inappropriate transport of ideas from one time to another, from one organization to another, from one culture to another or from one technology to another without the necessary critical evaluation as to whether they will really work in the new setting. It's like taking a rainforest fern and planting it in Death Valley without considering the conditions of the new location.
Like that thirsty fern, project solutions are highly dependent on their environmental fit for success.
Technology arises in response to environment. Specific technical architectures are needed to deal with legacy systems. Many of the things we build are quite different from what we would create in a pristine environment. We make architectural compromises to connect new systems and data to older systems. We design things to meet the security concerns of a particular organization or regulatory body. We build systems that reflect the organizational structure and territoriality of the users and even the technical staff. Some systems are built to accommodate the personal relationships and animosities of particular managers.
I'm thinking not just about the end product of a project, but about all the human technology that is involved in the creation of that end product. Processes are built to manage the structure, culture and politics of a particular place. Managerial approaches are specific to an organization or to the complexity of a project. Team structures either resonate or conflict with their host groups.
To address this risk, make sure that your projects are staffed with people with a mix of experiences, both technical and organizational. And watch carefully to ensure that ideas adopted from previous projects make sense in yours. Experience counts, but so does the critical assessment of why something worked before.
« Back to news listing