My team just completed an aggressive project to release a new, on demand, interactive report for our leadership. New business focus created the need for a different approach, so we undertook the challenge to rethink how we delivered this important data.
We worked the project in what we lovingly call our “scrum butt” approach. It’s not quite Agile/Scrum — it doesn’t have the discipline of these formal models — but it leverages the nimbleness of these approaches and lets our project team and experts leverage their creativity to solve problems as they work the project.
We started by confirming the need. It was well-enough defined and had urgency. Then we scoped a possible solution and provided some mock-up info. We “socialized” (I hate that term) the concept with leadership and a few key stakeholders. Surprisingly, this was enough to get international travel approval from 2 different departments (business and IS&T) for 2 team members from Germany to travel to our USA headquarters for 2 1/2 weeks to work this project.
We continued working on “socializing” the scope within our team and with a larger team of stakeholders and contributors. We assembled leaders, architects, and developers from 3 different departments to show case various solutions that already existed in this space. The goal was to get some agreement on a single future direction for all these silo’d tools. We were very pleased that everyone felt the same mandate and sense of community across silos. We followed the show case with another session to explore a new technology platform that might serve our own project and the next iteration of other existing tools. Again, we were surprised and pleased to find ready agreement in a common direction.
Finally, our team arrived on site and work began.
And you’re probably thinking that I skipped a few steps in my story. Not really. When the team arrived on site, we had a common vision and high-level outline of the larger buckets of work that needed to be delivered: a new data layer, a few key data problems solved, the interface of the tool built, and the PM side (communication, launch, training).
One key step that we skipped was gathering requirements. In this case, the requirements really were already gathered. We took the last 6 months of urgent reporting requests and the most recently delivered reports that had gone through several iterations already as our set of requirements. This way, we knew we had the salient things that were really needed and whose value had been proven despite some key data and platform weaknesses. This saved us from what typically becomes an uncontrolled expansion of requirements when we ask the open-ended question: “What do you need?”
With that high-level scope in mind, and documented very carefully on the war room white board (LOL), the team dug in and started rebuilding our earlier mockups in this new tool platform. This refined the scope, uncovered new problems, challenged some scope assumptions, etc. Every few days, we vetted conclusions with a few key stakeholders. We kept getting validation, and kept building, arguing, changing our minds, rebuilding, etc.
In the 2nd week of the project, we had a workable alpha version that we demo’d to the leadership team. They loved it and it validated all our assumptions and decisions. We finished refining it and it will launch on 05 Dec.
It’s loose. It’s sloppy. It’s nimble. It’s free. It’s creative. And it really does work.
But what makes it work? A team of people who work together all the time, who know each other, who are experts in their field, who know and live with the business requirements every day, and who are motivated to delivery something valuable and exciting.
You won’t find it in a text book. And purists will cringe and point out quite correctly all the risks and problems.
All I know is that we hit the mark and delivered in less than a month.
Related posts:
Category: 
