Archive for category Pace Layering

If you can’t maintain full speed for the entire race is it better to start fast or end fast?

We’d all prefer to maintain world record pace throughout if we could, but for most of us that is not possible, and in my view finishing fast is definitely preferable to starting fast.

After the event you will be remembered mostly for how you finished rather than how you started.

Focussing on finishing well cultivates a results based culture where outcomes matter the most.  A focus on starting well will push strategy to the front of the priority list.  When I have to choose I’ll select optimal results with reasonable strategy over perfect strategy and average outcomes every time.

A challenge for many IT organisations comes from a definition of success which allows a project team to claim they finished well long before results are in.  An IT operating model which allows projects to claim success because of on-time and on-budget delivery is missing the critical realisation phase where benefits are measured.  Many project teams have moved on or disbanded before the results are known which effectively leaves players congratulating each other at the three-quarter mark.

Imagine an athletic event which awarded prizes based on performance at the three-quarter mark regardless of how things looked at the end?  Crazy but exactly what many large organisations do with their IT projects.

I like to run my projects starting at full pace to establish momentum and a culture which can’t tolerate too many obstacles to moving quickly.  This is followed by a sustainable rhythm which allows all the players to last the distance.  Then finally moving back to peak performance after release where everyone is focussed on reacting quickly to customer experience and feedback. 

The cooling off lap and prize giving should only occur after measurable results are collected which match the project objectives.

No Comments

When do job titles matter in pace-layered IT?

Pace-Layered Application Strategy™ is a Gartner Concept promoting the division of application development across systems of record, systems of differentiation and systems of innovation.  The key point is these three layers require different approaches to achieve success.

I’ve spent the last 3 weeks bouncing between a large SAP project (system of record) and a smaller project (system of innovation).  The first has a large project team, an expected duration of around 18 months and a governance model appropriate for a large CAPEX budget.  The second has a very small agile team tasked with delivering a solution in 4 weeks within a limited OPEX budget.

The interesting observation I’ve made after the last three weeks is that job titles matter a whole lot less when building a system of innovation.  The team is outcome focused not deliverables focused.  Hand-offs occur between people based on skill rather than job title.  In contrast the project delivering the system of record is following an industrialised process with rigid boundaries defined by titles held by each team and team member.

One model encourages identifying blockages and figuring out who can clear them “today”.  The other model is based around responsibility for component deliverables rather than the overall result.  This leads to accountability not being shared across the large team with conversations structured like “that’s the responsibility of xxxxx” rather than “what do we need to do to get this delivered”.

The other observation I’d make is that an organisation embarking on a pace layered approach to application development needs to think carefully about which engagement partners to use.  The “right” partner will differ across the three layers.  Systems of innovation need more commandos and fewer generals as one example.  Systems of innovation need small numbers of people with multi-disciplinary skill rather than large numbers of people with well-defined but narrow capability.  This can be a problem for large organisations operating a “preferred supplier” model which gravitates towards engaging a small number of large firms, because in some cases these firms and the teams they deploy are not experienced in agile development where job titles become close to irrelevant.  Engagement partners need to be selected based not just on their experience in a particular technology but also their proven capability to operate in the pace layered tier being used for the project.

No Comments