Complex Projects
There comes a time in every project I do – whether it’s renovating a bathroom by myself or reverse engineering a complex business process – where I reach a point that gives me a physical sensation. It’s a similar feeling to the one you get when you are driving down one hill and up another and you feel a flutter in your stomach as you reach the crest. It’s a touch of scary mixed with excitement, disaster with fun, that always strikes at some point in a complex project. It’s usually when you realize that reality has exceeded planning and you begin to doubt your own ability to rein in the project’s scope and bring it under control.
I’ve found that these points, although scary and nerve-wracking at times, often turn out to be very useful. I’ve learned a lot from them. In the bathroom remodel I learned how to sweat pipes, lay tile, hang drywall by myself and sheetrock – the last which I am particularly proud of because it’s a skill that’s hard to do well.
Surviving these panic points is not easy; far from it. Panic and self-doubt mix into a fog that makes it difficult to see connections. They often conspire together to short-circuit my memory, making it harder to remember key requirements that would clarify the situation. Add in the pressure of a looming deadline and you have all the ingredients necessary for failure.
At my job as a systems analyst I’ve that the first rule when this happens is to resist panic. I do this by applying the second rule, “focus on the basics” – especially by applying a consistent and thorough methodology, rereading notes and emails, painstakingly reviewing code. Usually at this point I leave Microsoft Word and open Visio to diagram all the parts with all their connections. If I resist panic and keep a level head, making the information as visual as possible, turning concepts and scribbled comments into shapes, connections between data entities and processes become apparent and the scope that had broadened into a river gradually closes inward into a thin, manageable stream.
For non-IT complex projects I follow the same methodology. I’ll stop, read the directions, research on the Internet and in the case of the bathroom, draw diagrams on the wall, all the while resisting the urge to throw up my arms and shout to the Wife “I’ve had it. Call a professional!” Sometimes it’s enough to walk away from the project for a few hours and do something else then return later with a fresh perspective.
Handling complex problems at heart requires an acceptance and willingness to face them when they inevitably arise. I suppose that one could avoid them by calling for help or paying someone to take care of them when they do appear. But estimates on the bathroom the Wife ranged from $10,000-$25,000, so we simply couldn’t afford it. The renovation ended up costing us about $3,000 in materials but took about 8 months to complete. Complexity is at the very foundation of my job so the only way to avoid it there would be to do a job that isn’t complex. Those jobs tend to be menial and much lower paying than those requiring the skill of understanding and resolving complex problems.
Complexity is organic. I’ve learned in my job that confusing business processes or “spaghetti code” applications result from the conflicting requirements and business restraints that the processes or code must flow around in order to do something useful.
The tendency for an outsider is to get a cursory view of the business objective then leap to the conclusion that the only solution is to start from scratch. However they don’t realize that “starting from scratch” usually entails re-engineering not just the particular process or application they’ve been hired to analyze, but also all the processes, data feeds, and applications that feed into the targeted process/application as well as all those that flow out of it. Within a short period the scope of the project gets blown beyond anyone’s expectations or budgets, and the only way to not fail is what one project manager I’ve worked with calls “descoping for success” whereby features are yanked willy-nilly out of the project in order to come in on time and or budget. Using the bathroom renovation as an analogy, it would be like me telling the Wife that due to the complexity of the job we would have to forgo the full bath and settle on a half-bath. While some clients might settle for that, my Wife sure as heck wouldn’t.
That’s why it is critical at the start of any complex project to have realistic expectations of what can and cannot be done. This is more of an art than science since it involves, to use former Defense Secretary Donald Rumsfeld’s Three Knowns as an example, figuring out what we know, what we know we don’t know, and guessing at what we don’t know what we don’t know. The “known knowns” and the “known unknowns” are the scope of the project, and the “unknown unknowns” are the risks inherent to the project.
However Rumsfeld failed to mention the fourth “Known”: the “Unknown Knowns” – what we don’t know we know. It could be called “tacit knowledge” or “unconscious knowledge” but I think of it as “experience.” These “Unknown Knowns” are the assumptions of the project.
Recognizing and capturing the assumptions is critical to the success of any complex project. For business and systems analysts, invalid or changed assumptions are the leading causes of software defects according to Manny Lehman, Professor Emeritus at Middlesex University. In my bathroom renovation I had to recognize the assumption that the studs in the bathroom provided support for the walls and in some cases, structural support for the floor above. I had to make sure to brace any load bearing stud before I replaced it. This was a classic example of an “unknown known” that constrained my usage of the reciprocating saw, thereby slowing down the renovation and pushing the timeline out.
Since the renovation was a solo effort, my assumptions were based on personal experience; however in any team IT project these assumptions have to be written out and discussed by the group in a process called “base-setting”, “getting everyone on the same page” or my personal favorite, “having a come to Jesus meeting.” This takes time, and often has to occur several times in the span of a project, but the time spent is crucial to managing complexity and achieving success.
Experience has taught me that people do what works. They don’t waste their time following processes or using applications that don’t. It may seem absurd or time consuming at first glance, but if a process or application exists and has been in production, then it is successful and needs to be treated so – not as something that is broken.
Bathroom fixtures online:
Bathroom fixtures online
[...] and try to distract him from the subject. Stickers or cool bandages work like a charm in a time like this. Remove your bathroom rug before you start the training (I learned it the hard way). The whole idea of potty-training is about [...]
12 July 2008, 2:02 am