I find it interesting to see how most businesses plan for IT projects. The most common approach is for the business to get a set of proposed projects together, but get IT to cost them. They then decide on which one to do based on this input and what benefits are talked about and estimated costs.

When I see the costing process, I see it as heavy weight – lots of predictive plans with lots of magic weighting and theoretical costs. Worse still is that it sets the expectation that the cost is actually predictable when, in reality the detail you get and what it cost you from the original plan are far apart and you just spent a bucket load on this additional lengthy process (the estimate starts to become a promise).

An alternative I propose is a lighter weight approach with businesses focusing on what they want to do and not what projects a particular group within the business proposes. It’s more important to focus on the business problem first and the implementation details last so that both are aligned as closely as possible. After identifying what the business want to do they should next define how much they would like to spend. The amount needs to be feasible and measuring existing project costs and benefits and getting IT involvement is definitely required. Magic numbers plucked from thin air are never useful but do need to be balanced in terms of value maximisation and technical feasibility.

The focus for the project implementation should also be different from traditional methods. The focus should no longer be ‘keep to the plan’. It should instead maximise the value the business gets while keeping aligned with the business objective. Agile projects provide a great way of doing this by splitting down the detail into chunks that have identifiable value, getting the business to continually identify what is valuable in relation to their business objective and then getting the value faster and earlier than a big bang approach.

I’d love to hear what you think about this so please drop a comment.

Regular heart beat retrospectives are a useful tool for measuring how well the team is going. As someone responsible for project delivery, you want to maximise the amount of honest feedback you get (both positive or negative) as they all might pose risk to the project.

The amount of feedback you actually get is a useful indicator rating the team’s comfort level – either with each other, or with other people they report to. I’ve seen a number of feedback sessions stifled by one or two key people that sit inside the room, as people withhold their opinions for fear of negative consequences. Controlling people typically disengage individuals from the team and reduce the effectiveness of feedback you get. Uncomfortable silence or a minimal set of feedback are both signs that people may not be entirely comfortable.

Splitting the group into smaller teams might help to improve individual’s openness, introducing a speaking token so that one person is not always talking or even asking someone to leave is a last option.

The feedback I’ve most recently received on my latest project is how fun it has been. This enjoyment factor is common feedback I get when working on projects with agile values and practices. I do not think this theme is exclusive to agile projects but I definitely think it is more common.

I believe that projects run in this manner are a result of the Agile Manifesto statement of ‘Individuals and interactions over processes and tools’. A result of working closely together and striving for a common goal breaks down the focus on the individual and succeeds in building a fully functional team.

Why you should care as a Project Manager or as a Business Person?

Enjoying your work has a number of effects on the way that you work. I believe studies have disproved that happiness positively impacts productivity, but I believe that in the long term it still has a positive effect. More importantly I believe studies have proved that happiness positively affects staff retention.

If anything, my own opinions are that it works to reduce the overall risk of the project as each person builds on each other’s strengths and contributes positively when someone is at the low in their peaks and troughs. The similar alignment between all team members also leads to people improving the project in different ways because they want the project to succeed and not just because of individual motivations.

Note that working in this manner is not necessarily comfortable for all people but it’s usually because people have built up their own social barriers in order to work effectively in more traditional environments, or they don’t like working in teams.