Skip to navigation

malevolent design weblog

This blog is now defunct, but you can find more stuff over at my personal site

Think Before Doing

A suggestion for clients and developers: for non-trivial projects, treat the investigation/discussion/specification phase as a standalone project. Give it a separate budget and timescale, and don’t commit to precise features or accurate costs for the build phase until it’s all planned out. In fact, don’t even commit to who will be doing the building. There’s rarely a downside to this, and it has some clear advantages:

  • The overall objective is broken down into more manageable chunks.
  • The client and developer both get to see if the working relationship is OK with minimal risk.
  • It helps to ensure that the developer doesn’t skimp on consultation and planning (it’s sometimes tempting to go for an obvious, safe solution), and that the client sets aside money for it.
  • It avoids premature, ill-informed decisions (often the cause of failed projects).
  • There’s more chance of being able to find innovative ways to save time/money, or improve the final result.
  • You can’t accurately establish what will be produced for how much and by when until the thinking has been done, so why try? Acknowledging what you don’t yet know helps to reduce stress and confusion.

Unfortunately, as with being open about budgets, many people are oddly reluctant to consider this approach, but I find it works well.


Specification phase? Specification phase? We used to dream of specifications!

Perhaps the worst nightmare of an IT development project I ever audited had the following "specification". "Replicate the functionality of the old system on the new platform". I kid you not.

I'm attracted to the idea of running the spec phase as a mini-project but more inclined to treat the entire project as a business change initiative, not a project. Treating the whole thing as a means of improving the organization inevitably draws business people into the mix and forces the nerds to listen up. It leads to proper, informed discussions about costs and benefits, risks and rewards. Using ISACA's ValIT approach creates meaningful business cases and (the best kept secret) metrics to help management milk the eventual product for all it's worth.

Gary Hinson, NoticeBored, 29th Jan, 6:38am

Comments are now closed for this entry.