Project architecting for anti-progress 1

Posted on 15, May 2013

in Category practitioner experience


Authored by Chuka Madukwe

At the outset of every engagement, we spend time architecting the project to ensure that there is alignment between the organisation's strategy, the proposed deliverable of the project and the approach to be adopted. Over the years, we've seen many, uhm, less than optimal practices across the industry. We decided to write them up in a "cheat sheet" for project architects.

Project architecting for anti-progress

Make roles and responsibilities unclear. In fact, why even consider them at all? Just assign people to the project and hope that they will get on with it. This way, the real "diamonds in the rough" will get a chance to shine. It's Darwinism, project style.

Make your documentation as long as possible. Long documents are proof that you've consulted widely and thought hard. Stakeholders really appreciate them because they get a chance to be sure that every single conceivable exception, no matter how unlikely, has been considered. They also look really impressive on the desk. Aim for at least 250 pages (excluding models, these should be in a separate appendix).

Ensure that there are dozens of people engaged in review cycles. Surely it is better to get insight from everybody in the organisation? And customers. Not to mention suppliers and regulators. If you research and review requirements with a massive stakeholder group then you're sure to be able to deliver a fantastically thick requirements document.

Everyone needs to agree on everything before progressing any single decision. This is a project, not an autocratic government. It needs to be setup so that every decision is consensus driven across a wide stakeholder group. Especially the little decisions, those are most important. Documenting the never-ending email chains as decisions progress provides great content for your appendices.

Encourage teams to operate as functional silos during delivery. Talking to each other only slows things down and gives people the illusion of being involved. It's much better to ensure that different parts of the project team are minutely focused on their own work at the expense of anything else. This will allow you to write documentation much more quickly.

Waterfall. Only. Forever. Thinking through different delivery approaches will only slow down the project. Why waste time planning how to do something when you could be having meetings and writing documents? Those new fangled approaches are only a fad anyway, everyone knows the space programme / banking platform / other important thing was built using a waterfall approach.

Keep it big. Breaking up the scope into small manageable chunks only demonstrates an inability to be a big picture thinker. Also, you never know whether you'll get budget again so be sure to use it all in design and delivery. With all the analysis you're doing, it's almost certain that your design will be totally accurate.

Make change within the project complex. Don't let stakeholders fool you with changes to business priority and process. The point of the waterfall approach is to draw a line in the sand. There's no point in a line if you don't police it. Make it exceptionally difficult to cross that line. This will demonstrate how serious you are about meeting the project ambitions and win you respect across your stakeholder community.

Paper, paper and more paper. Don't be fooled by tools that allow either better management of requirements throughout the project or collaborative working environments. These too are a fad. There are many detailed spreadsheet templates that will allow you to track traceability across a complex design making for value-adding work on the project team. Paper will never go out of fashion.

Make workshops cover as much ground as possible. Your stakeholders are busy. And they need some time to be available to review your thoroughly written documents. Be sure to make workshops cover every angle - the more you can cram into a single whiteboard session, the better. Don't worry about focusing on the details, stakeholders often get this type of stuff confused anyway. It's your job to address this as you write out an activity diagram, use case and associated notation for every single process.

Measuring benefits is like counting up your old Italian Lira. Benefits only begin accruing after the project is complete. By then, you should be focused on some other important project or change. You want to be a forward thinker, not stuck in the past.

Do you have any more rules to architect projects for anti-progress? Let us know in the comments.


Project architecting for anti progress/practitioner experience

Chuka Madukwe
Chuka is a Lead Business Analyst who, at the time of writing this article (April 2013), was responsible for driving out business change in the eCommerce space at a world leading electrical component supplier.

1 Comments

  1. Another great idea would be to get as senior a stakeholder as possible on the project board and as many as possible. Because, you know, the more C-suite guys and gals on the project board – the better it will be.