Structure Trouble – Part 1

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.

structuretrouble

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.

Comments

Powered by Facebook Comments

  1 comment for “Structure Trouble – Part 1

  1. Ignacio Inchausti
    February 20, 2016 at 10:39 pm

    Dear Louise,

    Your post resonates strongly with a specific situation I find myself in currently. The group of projects I am managing are members of a “program” but have fallen foul of disconnects between resource, priority and scope management: dependencies between these dimensions of program management have broken down.

    I would add that to address the symptoms of the “structure trouble” your post showcases, review of business strategic intent and how the program supports this is fundamental; this in turn will help identify the appropriate governance structure/framework required, together with the structures to support the program (ie. a fit-for-purpose PMO and planning guidelines).

Leave a Reply

Your email address will not be published. Required fields are marked *