Heat map software for projects and bids

I’m a big fan of heat maps, they help me get across a huge amount of information to clients and my team in a single picture.

I use heat maps for projects and bid management. The software I prefer to use comes direct from Microsoft Research called Treemapper available to download here http://bit.ly/asGNWH – it includes an Excel plugin to make building your heat maps quick and easy.

Microsoft’s Global Product Development Europe have released a Silverlight version available here http://bit.ly/azNGmZ – I remember suggesting developing this to a colleague a while back now, my idea was to develop it as an internal bid management tool to improve the balance of a sales persons quote and the reality of effort and complexity. I also envisaged it as a Microsoft Surface app.

Microsoft’s Treemapper software doesn’t produce the most visually stimulating picture of your heat map so if you have access to creative designers and are working on a bid, it’s always a good idea to ask them nicely to make a pretty version of your heat map.

Enterprise Architecture books

I’ve had an Enterprise Architecture week this week and found myself flicking through chapters of two great books I’m reading at the moment, Patterns of Enterprise Architecture http://bit.ly/bbz6zB and Microsoft.NET: Architecting Applications for the Enterprise http://bit.ly/aAmXQi

It could be that what I’ve been doing is just another web application design but since picking up both of the fore mentioned books I feel like I have a new perspective on things and a more generic and common understanding – back to that ubiquitous language again.

It feels cleaner to describe things to a client that fits in with industry terms or in my case what’s reference-able in a published book.

As per the Wikipedia description http://en.wikipedia.org/wiki/Enterprise_architecture Enterprise Architecture (EA) describes the structure of an enterprise, its decomposition into subsystems, the relationships between the subsystems, the relationships with the external environment, the terminology to use, and the guiding principles for the design and evolution of an enterprise.

Being able to whiteboard and or sketch EA designs out quickly and in a low fidelity way is my style. Burning a whole day in Visio, reformatting, sizing, colouring etc isn’t the best use of time when you’re kicking off the design phase. But, to have those polished and reusable templates ready is key for when you reach the proposal stage.

Winning business with BDD – Behaviour Driven Development

I attended a great talk on Behaviour Driven Development (BDD) by Howard van Rooijen last week at the Agile South Cost group meeting http://bit.ly/dkfahW

BDD is used in Agile software development and essentially gets both technical and non technical people collaborating by using a natural language and as the title suggests describes how something should behave rather than the ins and outs of a particular function.

I have two specific interests around software development projects, one is how to sell them (from a pre sales point of view) and one is how to get the team up and running to deliver them. Understanding more about BDD will help me in both.

Firstly, don’t get me wrong, there are many aspects to winning a clients confidence when it comes to software development projects but BDD is one that you could throw into the pot to create that ‘common language’ from the start. By describing how a clients project will be run and delivered helps your client appreciate the value you will bring.

Simply speaking, there are 3 steps:

Step 1

Describe the concept of a product backlog item (PBI) – for example, as an online retailer; we want to be able to run ‘buy one, get the cheapest item free’ promotions for specific lines and products when a customer buys two or more items.

Step 2

Describe the concept of a sprint backlog item (SBI) – for example; define pricing engine to calculate cheapest item free when the ‘buy one, get the cheapest item free’ is activated against any given product or line.

Step 3

Describe the concept of writing a specification for said SBI but written as behaviour, for example:

• When a user adds 4 items to their basket
  • the cheapest item should be identified by the pricing engine
  • the price for the cheaper item should be zeroed.
• When the order has been successfully submitted
  • the order management system should be reconciled correctly
  • the customer’s credit or debit card is charged the correct amount for the order total.

The key word that makes this a behaviour written specification is ‘should’. This approach can then be used right the way through from development to testing. The same behaviour written specification can be interrupted by the test team and client because it’s been described in a ubiquitous language.

To me, it’s logical and from a work load point of view prevents doubling up e.g. the business analyst or project manager on your team doesn’t need to re-interrupt the specification because it’s written in a command language.