Work breakdown structure exercise
Today, I was invited to a WBS exercise given by a colleague. One of the absolutely best things about TUI Nordic’s project management department is that we all are eager to learn from each other. We are very different as project managers, persons and our experiences are very different. So, we keep a close culture of listening, learning and sharing. J is an excellent project manager, and I would feel really confident in him succeeding in big, complex projects. I feel I really have so much to learn from this guy. And today, I was again given the opportunity. J is project manager for a project. I’m not really involved but was invited to an WBS exercise. For him, it was a chance to get some new input since he’s new to agile software development, for me it was an opportunity to see how this really can work.
For you who’ve never done this type of exercise, you try to identify the different goals which need to be met to reach an objective. And then you divide the goals into smaller tasks and go on doing this until you have a picture of which tasks are needed. For agile people, this sounds like a story writing seminar, and this is exactly what it was. The goals are like epics and the different tasks are the user stories. We didn’t use the format of a user story but that are details. Instead of using story cards, J used post its and put these on the wall to show the structure. And since the post its weren’t big, there were not room for too much details. So, in other words, you get the shortness of a story. I loved the session, J is a skilled leader and used his two hours well. After this session I think we have a good idea of what needs to be done.
One interesting note was that in the middle of the session, I said we needed a Deployment objective. And then we needed a Maintainance objective. And suddenly the number of tasks exploded. Deploying a big e-com solution is something you need to plan for. You perhaps does not need an actual plan (in Project) but you need to plan for deployment. Make sure that the acceptance environment is available, that we have testers, that operations are ready, user and help desk informed. Etcetera. Etcetera.
Building the stuff is the easy part.