Structure is important in an organization of has any significant size. Granted, in an extremely small organization, structure may be irrelevant. An example I like to use to illustrate this point is that of an amoeba. An amoeba doesn’t have any internal structure (i.e. bones, skeleton). It’s just a squishy blob. The amoeba’s lack of structure is advantageous in situations where the environment is constantly changing. The amoeba can physically adapt quickly to mold itself into its environment. But if the amoeba grows too large, it will collapse in on itself due to a lack of internal structure. To put it in IT speak, amoebas don’t scale well.
I recently observed an amoeba-like project. It started small, with just two people involved in the day-to-day activities. The focus was to create a proof-of-concept application for business process automation and situational awareness dashboards. There was little project management type oversight, few rules of engagement, etc. It was a true experiment in Agile/Extreme Programming type work – and it was extremely successful.
Fast forward to the follow-on work. The team grew to 10 people overnight, with two interdependent work streams. That’s a big amoeba. Astute leadership would have recognized the need for internal organizational design and structure in the vastly expanded project. However, the PM and Deputy PM opted for carving the amoeba into two independent teams, one focused on each of the interdependent work streams. (Anyone see any potential for problems with that approach? Note the italicized words.)
About four months into the one-year project, things were undeniably unraveled. I say “undeniably” because while they were in fact never raveled to begin with, leadership insisted things were running smoothly until about the four-month mark. At that point, their “master plan” was not being achieved, in part because it was never conveyed to the team (where there is no vision, the people perish – Proverbs 29:18), but mostly because there was no thought, no plan, no structure in place to enable the team to achieve success.
To their credit, the PMs acted upon my commentary about structure and design for similar projects. However, like an OCD person with a newfound fetish, they went way overboard. They had structure. Boy, did they have structure. But they missed the two most important phrases in my diatribe about organizational design: first, that there should be an abundance of thought and critical analysis put into the effort (there wasn’t), and second, that the resultant structure must enable success for the team (it didn’t).
Now the project stands at a critical juncture. A competitor has entered the picture, and is demonstrating success where this project team hasn’t. The good news is the situation presents an opportunity to readdress the organizational design and structure issues for the project. And this time, rather than just coach them through the process, I’ve decided to take the lead on introducing some creative, non-standard, unorthodox, and even off-the-wall approaches to the organizational design issues. If nothing else, it will be an entertaining conversation.
No comments:
Post a Comment