A project case study where Yammer came to the rescue

You can never trust a case study to show you the true roots of success and failure. There are usually too many complex relationships between the moving parts to properly parse out the lessons. Despite that I want to share a story about a team using Yammer to overcome some of the challenges that beset it. Yammer is not the solution here. Decentralised decision making and wide open collaboration are. Yammer was just the tool at hand on the day.

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.