BPM Collaboration: The Good, the Bad, and the Ugly – Part II

Leading on from the first part of this month’s blog, columnist Dan Morris delves deeper into how we can promote, tackle resistance and govern collaboration successfully…

 

Collaboration: Avoiding Participation Chaos 

 

The more people with different points of view and individual ideas on professional disciplines (like Six Sigma or Agile) the greater the potential for innovation, but also the greater the possibility of team conflict. If team members are not flexible or if they start to worry about project failure they can become overbearing in promoting their discipline and their ways. 

 

So it is important to insist on the right participants to avoid creating a team that requires the manager to “herd cats”. This willingness to cooperate and be part of a team built on mutual respect is critical in successful collaboration and must be a goal in putting the team together. It does need to be stressed that this does not mean selecting a team that you know will agree with you, rather a team that is committed to cooperating. The differing points of view are critical for the development of any real solution.

 

“The fact is that people who join the team need to want to fit in and contribute.”

 

Controlling collaboration and involvement is needed more than ever because people generally have little time available for anything outside of their normal daily activity. Managers and staff have been cut to the point where in most companies there is little elasticity in what people must focus on. This has a serious impact on the way project participants can engage in projects. But we do want their involvement – we need their opinions, insights, and operational or other knowledge to be considered in the design of any improvement. We also need their involvement to promote their acceptance of the solution.

 

So the question becomes: “How can we promote collaboration without it driving a project to chaos – and increase risk and cost?” This has proven to be very difficult… 

 

• Beginning with an agreed upon scope, the team must accept the approach and techniquesthat will be used. Everyone must be dedicated to making the project work and be successful.
• Different groups need to be involved at different times in the project. So they move in and out of the team and must deal with the work others deliver – and the quality of that work.
• Different perspectives and disciplines are needed at different design steps and project design milestones. All must be melded together to produce a high quality innovative product.
• Different skills are needed from these groups at different times and all must be blended. Quality and pre agreed upon content and formats following consistent standards are critical to avoid rework and unending iterations.
• All involvement must be coordinated for the staff from different participating groups. Different components created by different groups need to follow standards and all must be monitored and quality checked so the components will fit together.
• Everyone needs to be kept advised of all decisions from all the groups to determine the potential ripple / impact of each decision on other parts of the design and the business operation.
• And the list goes on…

 

Collaboration Governance

 

So who will plan, organize, and control this collaboration? Is it the sponsor? Is it a vote by the collaborative team? Is it the PM? How will they do it? What approach will be followed? What techniques will be used? How will consistency be controlled? How will staff be evaluated? Who will have the authority to settle differences and make decisions? How will this be done in a way that stops endless debate and moves to decisions and action?

 

I believe that legitimacy requires the direction of a formal methodology that is built to control “collaboration” and “orchestration”. This should be an execution-oriented methodology and it should leverage the perspectives, techniques, and skills of all the disciplines from the various participating groups. If the company doesn’t have one, I suggest that one be purchased or built as quickly as possible.

 

The purpose of an Orchestration methodology is to tie all methods, techniques, and perspectives from the different groups participating or collaborating, into a higher level view of activity and timing. The Orchestration methodology must link to or pull in activities from different participant group methods and leverage their techniques at appropriate points in the project. If this Orchestration methodology is built in Microsoft Project or a similar tool, the combining of participant disciplines, methods, and tasks will create a combined project methodology that leverages all the strong points of the participants.

 

Such a methodology gives validity to collaboration governance and its standards need to provide direction on how staff members will interact with one another – what people can expect from one another and how disputes will be handled.

 

For this reason I recommend that any mid-sized or greater project require that the project team work with participants and “agree upon the rules of participation” – (who, what, why, when, and where) and look at how the various disciplines, methods, and techniques will be mixed to support the needs and timing of the project. In doing this, I recommend that different geographic-based cultural requirements be considered and built into the rules of participation and the methodology standards that will be used.

 

Collaboration – More than Nice to Have

 

I am a proponent of collaboration and active business (and at times customer) involvement in improvement projects. But teams must take the time to set the project up for collaborative participation and managers need to build interaction rules, define roles, define deliverables, and map out how each participant’s contribution will fit into a deliverable or work downstream. This collaboration guide can be built and formalized for the company and then customized for each project. 

 

We also know that the best way to avoid these problems is not to fall back on “iteration” and “the next iteration will fix some weakness”. We know that the best design is one that can be tested in simulation and then reviewed by all participants prior to any application generation (through a BPMS) or a build using traditional programming languages. This is really the whole purpose of collaboration – to create a new business operation that actually makes things better for all involved. Doing this with low risk and controlled cost is the project objective and part of determining success. But, in reality, the real value of the project comes from the creation of a better business operation – in the collaborative opinion of all who will be affected and thus benefit from the project.

 

I would like to thank my readers for taking the time to read my columns. I hope you enjoy them and that they give you food for thought. Please send any comments or questions toDaniel.morris@wendan-consulting.com I would like to thank Rod Moyer, of Wendan Consulting, for his help in creating this column.

SOURCE: processexcellencenetwork