|
[Printer Friendly Version]
A Stack of Problems: Five Ways Tech Projects Fail
By Michael C. Gilbert, February 28th, 2008
One of the most popular Gilbert Center seminars is Nonprofit Technology Consulting Skills, which we are offering in full on Friday, March 14, 2008. One of the key concepts from that seminar is the notion of a "stack of problems" for technology projects and I've been asked more than once to write it up.
When you're driving and you have trouble in a turn, usually it's how you entered the turn in the first place that's the cause of the problem. When you're in school and you're struggling in a class, usually it's what you did before the class itself that's the cause of the problem. When you're on a long flight of stairs and you can't catch your breath, usually it's what you did in the years before that's the cause of the problem.
Each of these is an example, with progressively longer time frames, of the same phenomenon: A problem whose solution best lies within an early stage of a process is often made manifest at a later stage of that process.
Understandably, most people don't like this fact very much. (The longer the time frame in question, the more they don't like it.) Naturally, they don't like it in the moment of discovering the problem. Nobody likes hearing that it's too late to fix something. Nobody enjoys the sinking sensation that comes from paying the price for a mistake made long ago.
The real problem, however, is that people don't even like hearing this when there is time to do something about it, when someone has seen the problem at the earlier stage in question. They want to be taking that class right now, not studying the prerequisites. They want to be climbing stairs right now, not getting in shape to do so.
Information and communication technology projects are not immune. People want to spruce up their website, not develop their understanding of the online needs and behaviors of their visitors. People want to send email asking for money, not cultivate relationships so that people are ready and willing to give. People want to do knowledge management, not define what knowledge and learning mean in the context of their organization.
There's a lot going on in this phenomenon, most of which is not in the purview of this article. Board-staff issues, leadership skills, funding dynamics, and many other factors affect the ability and willingness of organizations to invest in prerequisites of any kind. But having a clear vision of the causal relationships at work in a technology project can help some organizations avoid many common mistakes.
The following Stack of Problems represents how five key elements of a technology project depend on each other. I've chosen the idea of a "stack" for two reasons: (1) It's simple and intuitive, in that the upper elements rest upon and rely on the lower elements. (2) It's a familiar concept in information technology, where software itself can be said to be built upon stacks, where each layer is built on the features and reliability of the layers below.
At first glance, you may look at this stack and think it is a reflection of a single software development model -- the monolithic, waterfall model. That's not true, this stack can also be rapidly iterated in what might currently be called the agile model. And frankly, I come down firmly in the middle of that particular debate, believing that a healthy relationship between top down and bottom up processes make for good projects. One of the reasons why this is presented as a stack, rather than as a flow chart or timeline is that this represents conceptual and structural dependencies, not a grand sequence of events.
What follows is a quick definition of each element of the stack and some commentary:
Business Model: A model of how a project will create value for its stakeholders, describing its value chain structure, its revenue issues, its positioning, and its competitive strategy.
Some of this language may seem alien to nonprofit sensibilities, but it doesn't need to be. We shouldn't treat stakeholders as "customers", confuse sustainability with "profit", or measure value in terms of money. But software projects must create value of some sort for its various stakeholders, must do so sustainably, should pay its bill somehow, and should be bolstered, rather than undermined, by alternatives.
Communication Map: A media-independent model of communication constituents, flows, assets, and business processes, along with related analyses.
For information and communication technology, nothing is more important than understanding these patterns, except for the strategy and business model on which these patterns are supposed to rest. Nevertheless, most technologists still don't place this element as deep in the stack as it needs to be and the consequence is failed software projects.
Interfaces: The connections between the project and the humans and machines with which it must interact, including standards, protocols, policies, procedures, Application Programming Interfaces (APIs), and user interfaces (UIs).
This is the connective tissue of a project and flows naturally from the communication mapping. In an increasingly modular, interconnected, and user-centric world, this is becoming more important, not less, as time goes on. Sadly, they are often still afterthoughts.
Requirements: A hierarchical planning document, founded in communication and business processes, defining what a technology should do, including functionality, properties, and constraints.
This is where we finally enter the realm of most technology planning, whether conducted monolithically or iteratively. The hierarchy keeps features grounded in the deeper layers of the stack and prevents them from becoming shopping lists based on vendor promotional material or thoughtless pursuit of the latest and the coolest.
Architecture: A coherent set of designs, founded upon the requirements, which facilitates conceptual integrity, modularity, change strategies, and life-cycle management.
The very top layer of the stack, before the specifics of the project itself, is architecture. You might say that good architecture, as a process, involves the entire stack and that would be true. But too often, it reflects an insular vision of design as the purview of designers and software as the purview of engineers.
There are several ways to use this stack. Probably the most effective is to use it preventatively, to take affirmative steps early in the process to invest in every layer appropriately. But we don't always have the benefit of such foresight. Sometimes we may have to use this vision to compensate for deficiencies in the midst of a project or even mitigate for them after most of the available resources have already been expended. In any case, I hope this little Stack of Problems can help you shift some of those resources to the foundational elements in the next project in which you find yourself involved. Let me know!
If you found this article interesting or helpful,
please consider making a donation to Nonprofit Online News.
It will probably feel good!
|
RSS