Project Management – Page 3 – IS Survivor Publishing

Outline Thinking: Preventing pre-frontal paroxysms

Last week’s KJR introduced 20 ways of thinking something through, beginning with Outline Thinking and wrapping up with the satisfying but unilluminating Ridicule.

Honesty requires this disclaimer: While I’m quite sure none of these are original, I’m even more sure I didn’t plagiarize someone else’s list. The only credit I can claim is that of the numismatist: I don’t know who stamped these coins, and the only credit I can claim is that I’ve collected them.

Some of you asked for a deeper look at the 20 ways. And while I might stop at 19 – I doubt the world needs techniques for creating better ridicule – I figure starting with Outline Thinking – the first item on the list and arguably the most useful of the bunch – is a safe, if dull bet.

Outlining is top-down decomposition. It’s tempting to stop there, making this the shortest KJR ever posted. But that would be wrong.

Outlining is the tool of choice for documenting your understanding of a subject – of the details and how they fit together.

A successful outline begins with a good subject. It then breaks that subject down to between three and maybe nine topics that are of the same type, and which, taken together, fully encompass the top-level subject as viewed from that perspective.

For example, the subject of your outline might be a project you need to organize. You’ll have to address a number of different topics. For example you’ll have to think through the project team’s composition … that is, the roles you’ll need on the team to do the project’s work. Then there are the work products its team will have to produce to accomplish the project’s objective and goals.

And, not to be ignored, you really ought to figure out the tasks the team will have to execute to create those work products.

To figure out what these tasks are, the project manager will need to outline them. The project management buzzword is “work breakdown structure,” but don’t let that throw you – it’s an outline. So far so good.

You start the process of organizing project tasks by answering the question, “What are the tasks that make up the project?” That results in a top-level view of the project task outline, as shown in the box at the top left in the figure below, taken from the demonstration project used in Bare Bones Project Management – implementing a warehouse management system.

*Figure: Outlining is progressive decomposition*

Next, you ask the equivalent question about each project task that you asked about the project: “What are the sub-tasks that make up this task?” The figure’s middle box shows the result for the “Gather data” task, re-casting Gather data to Gather information requirements to help clarify what will be needed. In a real project you would ask the same question about every other top-level task, too.

The figure’s lower-right-hand box shows the result of taking the Conduct interviews sub-task to one more level.

Then you would continue until you run out of sub-sub-sub etcetera tasks. Or, if you’re smart (and lazy, but that’s just saying the same thing twice) you’d delegate the rest of the outlining to the experts on your project team best-suited to do so.

Bob’s last word: As you can see, outlining is an excellent tool for thinking a subject through to understand it better, whether the subject is project tasks, the components needed to assemble a piece of Ikea furniture (pro tip: yes, an Allen wrench is a necessary component, but no, it isn’t a sufficient one), or a meal.

What makes it such a useful tool is that it lets you understand the subject you’re figuring out at whatever level of depth you need, without having to keep all that depth in your head all at once.

Outlining, that is, is a terrific way to keep your head from exploding.

Bob’s sales pitch: Speaking of thinking, The Cognitive Enterprise, which I co-authored with my colleague Scott Lee, is, so far as I can tell, the only business book with “cognitive” in the title that isn’t about applying artificial intelligence to business situations. It asks what we think is a more profound question: What would an enterprise that acts purposefully look like – one that has more in common with predators than with ecosystems – and how would you build one.

Agile vs Waterfall, one more time

What do you do when someone else’s evidence and your logic collide? You might:

Use ad hominem “logic” to cast aspersions on the someone else.
Not waste time bothering with ad hominem logic – just deny the other side’s evidence.
Create a strawman version of what you’re trying to refute – something that resembles it, only with a few fatal flaws added to let you “prove” it can’t work.
Embrace your confirmation bias. Find someone on the internet … anyone on the internet … who asserts evidence supporting whatever position you like best. Cite them as the only authority worth paying attention to.
Redefine the criteria for being right.
Find a historical case of a scientist whose colleagues ridiculed their theories, only to be vindicated in the end. Claim they’re your ideological brethren. Whether the historical scientist was actually subjected to ridicule or not doesn’t matter.
Or, reverse the last stratagem: Find a theory that was popular once upon a time, only to ultimately be proven wrong. Those who disagree with you would have agreed with it.

Which brings us to the sad, sad case of why Waterfall methodologies persist.

In case you’re unfamiliar with the term, a Waterfall methodology is one that designs a project plan in terms of a linear progression. For application development these would typically start with a feasibility study, followed by requirements definition, specifications, coding, testing, training, and deployment.

With Waterfall methodologies, design has to be complete before development can begin, and if anything has been left out, or a design assumption has changed (as in, “Oh, you wanted wings on that airplane?”) whoever is championing the change goes through a change control process, which includes the project manager rippling the change through the entire project plan.

Agile, in contrast, is a family of methodologies, not a methodology. What its variants have in common is that they build software iteratively and incrementally. The list of Things the Application is Supposed to Do is called the backlog.

Projects still start with some form of feasibility study, one of whose work products is the initial backlog; another is defining the “minimum viable product” – the irreducible core of the planned application that everything else hooks onto.

From that point forward there is a process for deciding which items in the backlog have the highest priority. As for anything left out of the backlog or a change in design assumptions, these are pushed into the backlog where they are subjected to the same priority-setting process as everything else.

This will do as a barebones sketch. If you want more, please refer to chapter 3 of There’s no such thing as an IT project, Fixing Agile.

The best available evidence, from the widely respected Standish Group, reports that Agile projects are fully successful at nearly twice the rate as Waterfall projects, which fail completely about two and a half times as often as their Agile counterparts.

Case closed? If only.

Some Waterfall proponents counter with one or more of the denial strategies that started this article. For example a popular strawman is that Agile can’t work because in order to optimize the whole you have to suboptimize the parts, which supposedly can’t happen because in Agile, each developer does whatever he or she wants to build a capability that accretes onto the accumulating application.

This is a strawman. Agile projects build to a well-defined architecture, to user-interface standards, and to an overall coherent plan: Anything added to the backlog has to be consistent with the rest of the backlog.

Meanwhile, the implication is that in Waterfall projects, designers can optimize the whole. This assertion is, in a way, accurate. Designers can optimize the whole, so long as the target “the whole” is shooting at doesn’t change over the life of the project.

Good luck with that. The specifics of what a business needs to succeed within a given application’s domain change all the time.

So by the time a Waterfall-developed application is done, the criteria for “done” have changed.

Bob’s last word: The specifics of what a business needs to succeed within a given application’s domain changes all the time in successful businesses. Leaders of successful businesses know that their success depends on continuous adaptation to changing circumstances.

Success, that is, depends on agility.

Bob’s sales pitch: “To optimize the whole you must sub-optimize the parts” is a well-recognized principle here in KJR-land. If you’d like some guidance on how to apply it to your own real-world situations, you’ll find it in chapter 2 of Keep the Joint Running: A Manifesto for 21^st Century Information Technology, which explores this concept in depth.