Jason was frustrated.
As the developer in charge of the system to integrate third-party data from another contractor (XYZ, Inc.), Jason had requirements and some initial specifications, but as things changed there were questions that came up.
Bottleneck - by Aidan Jones via Flickr
Because it was another contractor and company who was going to be producing the data, Jean didn’t want to expose Jason to the politics or potential sharing of company intellectual property. As the project manager, Jean saw part of her role as “dealing with the other contractors and the client to free up my team to be productive.”
By the water cooler, Jason was sometimes heard to say something like, “It’s really hard to know what I should be working on when the people I should be working with are ‘over there’ and the only way I interact with them is through documentation and my project manager. I have to make so many assumptions and it’s hard to be motivated when I know everything I’m working on this month might be wasted effort if one of those assumptions is wrong.”
Let’s use one of many possible toolkits to evaluate the situation, the Theory of Constraints.
Step 1 – Identify the system’s constraints
The constraint in this system is the communication between Jason and the XYZ’s developers. There is so much friction there and degrees of separation between the minds that need to work together.
Step 2 – Decide how to exploit the system’s constraints
Let’s look at a few options.
Jean could be better about communicating between Jason and XYZ. Perhaps it could be her highest priority to do this. But wait, there are lot of other demands on Jean’s time. And at any rate, this solution doesn’t solve the degrees of separation problem.
A better option might be to open up communication channels between Jason and the XYZ’s developers. Looking for the root cause of the constraint, we can find that fear and a lack of trust is really the underlying cause, so this option addresses that root cause directly. One of Deming’s 14 points is to Drive out Fear and Create Trust.
Step 3 – Subordinate everything else to the above decision
This may be difficult. Perhaps XYZ is very fearful too and doesn’t want their developers talking directly to other developers and potentially sharing company secrets. Jean may need to work on building trust and bridging the gaps.
We have decided that communication between Jason and the XYZ developers is the constraint to optimal throughput (productivity) in this system. Therefore we don’t try to address other potential areas for improvement in this system until we have elevated and broken this constraint.
Step 4 – Elevate the system’s constraints
The process of 1)trusting your employees and 2) garnering trust between you and the other companies you work with can take some time. Jason may need some training on ITAR or export compliance depending on the nature of the work and if XYZ has foreign developers. He may need company-specific training on IP and non-disclosure.
Then Jean can really get out of the way and focus on removing more obstacles from Jason’s path, instead of being one.
Now Jean and Jason can focus on elevating the communication further. Perhaps what started as weekly conference calls with project managers involved moves to developer-only discussions. Then perhaps remote collaboration tools are brought in like online white boarding, collaborative coding/documentation applications, and video conferencing.
Step 5 – If in the previous steps a constraint has been broken, go back to Step 1
Once this constraint is broken, it means that something else is now the limiting factor in Jason’s productivity. At this point we go back to step 1 and look for other constraints. Perhaps some specialized technical training would take Jason to the next level.
An important point is that all the technical training in the world wouldn’t have made much difference to this system as a whole unless the bottleneck (Jason’s communication with XYZ) had not been addressed first.
Another important point is that this is just one sub-system among many that make up the whole “system” that is a project. If we zoomed out we may find other areas of the project that are in much greater need, and as we broke those constraints we would eventually reach this one.
What did you think of this little thought experiment, and how would your analysis be different than mine?
No related posts.
{ 2 comments… read them below or add one }
Hi, thanks, I like your thoughts. I was working on my first project and there was a rule that the people who were testing the new system – and representing the end users – were not allowed to talk directly to the developers. The rationale was good, the developers were supposed to be working and not figuring out what the user/tester needed. It was supposed to focus the team and reduce scope creep.
What happened was a culture of frustration in the two teams and conflict on priorities with the end user. One day a developer came up to the testing room and started a conversation. The rule broke that day and the project teams became much more effective.
Thanks for the comment Perry! You and I have had similar experiences then. I remember talking to a project manager once about the way projects were run in her company. She described an organization where project management was on one side of a fence, and submitted requirements to a development department. Just as in your example, the developers were left to interpret requirements without the benefit of direct communication with the client or end users.
I admired that project manager for not having gone crazy (yet) because she never knew when the development department would complete their deliverables. They had a complex priority system that executives over-rode on a consistent basis by escalating their own pet projects through the system.
-Josh
pmStudent e-Learning