The situation
A project got out of hand. Lack of sufficient formal leadership
and an over-hierarchical organisational structure and culture appeared to be
the main roots of the problem. The project manager was calling out for help but
no-one was able to hear him. Eventually
the project crashed.
The project manager was stood down, the consultants were
called, the project sponsor was wondering what happened. A search for a new project manager was
initiated; someone who was high end and able to rescue this apparent disaster.
What happened?
While the consultants sorted through the rubble and the search
for a new program leader was undertaken the software guys opened up a Yammer
group and asked the users if there was anything useful they could do while they
waited for new orders.
The user community responded with pain they were feeling day
to day.
Many of these issues were small and could be fixed within a
few hours to a few days. One by one the
small team addressed each of the user pain points. The user community got more
involved and active in alpha testing releases and offering feedback on what to
work on next.
The software team continued to work on small incremental
changes, without direction, without requirements specification or even user
stories. They were just working off dialogue in a yammer group.
The outcomes
Everyone in both the user community and the software team was
happy with the improvements. Many long term usability issues were fixed. Business
outcomes were achieved. Value was created.
Unfortunately what the user community was articulating were
operator issues, and not specific to the program agenda.
When the new program manager was appointed he maintained
some capacity for this to continue, but had another job to do as well which was
to shift from internal to externally managed infrastructure. This was
unfortunate as it limited the team’s ability to work to the user community’s
agenda.
The new agenda was mediated by a desire to reduce operations
cost (which wasn’t achieved by the outsourcing by the way) and by a middle
management layer inserting it’s own agendas into requirements.
Lasting effects
The lesson was there, and understood by the people in that
community. User engagement and participation in alpha testing remains in place a
few years later. I understood they were going to stick with a release and
recover strategy rather than a test first approach but the organisation was
inclined to suppress that sort of behaviour.
The overall approach to connecting developers and users and
prioritising work through that channel wasn’t sustainable though, as the developers
were funded by a project with a specific end state. Once that state was
achieved the team was essentially dispersed and the system left in the state it
was in with only critical failures attended to.
What’s the lesson
here?
Over and over again we see teams do great work, but they are
let down by the environment they operate in.
Theses successful teams are necessary to stimulate a change the way we
do business, but we need to work harder in adapting the whole system to
innovation.
What can you do?
What can I do?
I suspect maintaining some capacity in your day and week to
talk to the people who manage the supporting infrastructure and make sure you
can deliver wins to them that encourage them down the same path you are
travelling.
