In our January newsletter I told you I would start to share more regularly my own experiences and observations from not just my past but real time experiences from the projects am currently involved in or that I see in organisations around me right now.
Here’s my first article. Let me know what you think and what you want to hear more of.
Today I observed an interesting conversation about program structure. I quietly listened (trying very hard to keep quiet) to the different views and opinions of how a program should be structured.
Defining the structure of any project or program is actually one of the most challenging tasks you have to undertake when getting set up. It is however, one of the most critical tasks to get right.
Why do we have structure?
In simple terms, the purpose of the structure is to:
- demonstrate ownership
- represent accountability
- enable those involved to understand where they belong in the program
- show who team members are accountable to
- who to ask questions of
- show how work will be managed or delivered
There is no one right or wrong way to structure your project. It may demonstrate the way you intend to deliver the work or it can demonstrate the reporting lines and accountability of scope items, plus many more variations on that. If you’re lucky the structure will give you all of those things.
Handing off work not accountability
The challenges that the people in the discussion had was that they were currently structured the way they were going to deliver the scope. In this particular circumstance, this meant there was nobody in the structure that had end to end accountability for each scope item from initiation all the way to implementation. The responsibility and accountability was dispersed. The responsibilities were broken up by the phases of the life cycle of that piece of scope.
Let me give you an example. One stream of work was responsible for understanding what the business needed, the requirements. However, they then handed off to another team to develop components of the solution and then it was handed back for responsibility of testing and this responsibility would go back and forth for various phases. In this particular instance accountability of the delivery was also handed off. That is a very simplified example but you get the idea.
I’m not saying this will never work. However, in a large program with continual deadlines, potential conflicting priorities and large amounts of pressure, if no one person or stream has ultimate accountability of making sure that scope item effectively moves through the entire journey of its lifecycle, there is a huge risk it may not make it to the end of its journey in one piece, or at all.
In my mind something that is put in place to reduce risk, the structure of the program, has ended up creating risk.
The possibility of things falling through the cracks, going off plan and scope creep become quite high. With no end to end accountability, how does the director of the program have confidence that all elements are coming together coherently to deliver the outcome they have been asked to deliver.
These two views, one saying we believe we can effectively manage the deliverables with the handoff points also handing off accountability and the other saying there is a need to have end to end accountability, created quite an emotional discussion.
I am sure you can work out which camp I am in.
Now that’s my opinion. I would love to hear yours.
Tomorrow I will continue this story and start to get into the dimensions of power and control that started to come through.
About the Author
Louise Ledbrook loves the project world and is continually looking for ways to improve how we deliver projects to reduce cost and risk and to make it a more enjoyable and successful experience for all involved. She is the Founder of Project Community and the CEO of Pro SMART. You can follow Louise on twitter @louiseledbrook or on Linked In.
Powered by Facebook Comments