Collaboration is touted by many as one of the big breakthroughs in BPM. I agree with that position. It is a big deal in my opinion – when it works the right way. However, when it is not properly planned or supported it can be an extremely disruptive force. The issue is one of controlling participation and contribution – applying the right background, skills, disciplines, and knowledge at the right times and controlling all contribution content, format, and team interaction.
The great part of collaboration is that it is an excuse to get people who will be affected to participate. I have personally managed projects with international business and IT staff members for business functions in multiple geographies. It can be fun to work with the differences that people bring to the project – but it can also be more than a challenge.
When properly controlled, the results of collaboration can produce exceptional results. It can improve the possibility of innovation; it can deliver broad acceptance; and it can bring people in different geographies to a common way of performing the work that was in the scope of the project.
However, there are challenges with differing policies in different geographies and differences in law and the way people can legally work together. There are also differences in tool agreements, such as the use of BPMS tools suites and their license agreements. And, of course there are significant time differences that may need to be considered. But, when you have gone through that once, you will have an idea of what to look for in any future collaborations, so these issues are really part of collaboration start-up.
Collaboration and Real Involvement
I have found that just because a person has been assigned to be part of a collaborative team, it does not automatically mean the person will engage and be involved to the extent he or she may need to be. Involvement is really a matter of priorities – which can quickly impact commitments. This is especially a problem when groups in different geographies are involved. In these projects, actual work effort is hard to control and actual status is really impossible to accurately evaluate until a deliverable is due.
This risk can be minimized by:
- Having frequent small deliverable components that will later be blended to form the person’s product – giving insight into performance and quality
- Having formally agreed upon staff alternates in each geography who can step in if necessary
To make this work, the requirements will need to be included in the project collaboration standards and applied to all projects that have staff in multiple locations.
In addition, language and associated accents can present barriers that must be mitigated. I have been on projects with international teams where some members use language and understanding what they committed to as excuses for non-performance. To avoid this, all agreed upon activities should be confirmed in writing. There will always be bad apples in any group and when found need to be dealt with according to company policy.
In addition, we cannot presume that affected business managers or their staff will agree to be involved in a business improvement project. While on the surface the need for this involvement is obvious, the real world often intrudes. We all hear “We don’t have time to get involved”, “We never get what we want anyway – IT just does what they want” and a thousand similar excuses for not participating. The unfortunate fact is that many companies are running so lean, that they really do not have an ability to spare staff time without it impacting the operation. Upper level support is critical to make certain that key people can participate when this situation arises.
To succeed we must have adequate business user participation. At times we have adjusted to this through planned overtime of the person we need to see or for someone who will fill in while that person is with the team. The way to deal with this will vary by company and possibly by union agreement, but if there is participation problems the sponsor must work them out with the participating department managers.
So, I recommend that each member of a collaborative team be assigned a formal role – with written expectations for time, contribution, and commitment. This allows the manager to promote actual involvement and monitor real participation.
Controlling Collaboration
Managing a truly collaborative international team is different from traditional project management and the project execution, which I look at as being different from project management. It requires a new set of skills that are based on conflict management and the authority to govern the team – and control the team’s interaction dynamics. To a large degree, it also requires an ability to infer from the information that you are given to avoid finger pointing and provide control over situations that you can only influence – if people are not in front of you, you need to find other ways to manage them.
The most potentially volatile situation that must be faced is that everyone brings a different perspective, driven by different experience and following different disciplines, standards, and rules. These are personal biases and we all have them. At times, project participants will have issues with other disciplines, their approaches, philosophies or techniques, or project management methods. This conflict is often apparent between Process Architects, Business Architects, and Enterprise Architects – all of whom often believe that business transformation must follow their approach.
Melding the use of these disciplines and their approaches is challenging, but it can be and needs to be done for each project requiring multiple contributions from people with strong feelings about their chosen disciplines. It is also much better to debate this out ahead of time – as early in the project as possible and reach a consensus that everyone needs to agree to follow. There will still be grumblers but anyone who may try to sabotage the project so it shifts to their approach will need to be closely managed or may even need to be eliminated from the team. So acceptance of a negotiated approach that leverages the best of all the participant disciplines should be considered to be a critical milestone in the project.
While the whole purpose of collaboration is to gain access to these unique potential contributions, unless there is pre-planned and governed, interaction chaos can easily result and the project actually deteriorate into a mess. While to some extent this is a project management issue, it is even more an issue of participant and contribution orchestration and approach control. In this context, orchestration is the governance of deliverable design and the strength to meld differing opinions, disciplines, and perspectives into a single cohesive approach to task execution.
When supported by a BPM modeler or full BPMS product suite, this collaboration can include the ability for people from different parts of the business, different business partners, and possibly customers to work together on models and contribute to a change in a business operation.
That is 'the Good'!
However, as noted above, an unintended consequence of collaboration is that it pulls in people together who have very different ways of doing things, different problems, and different opinions. If some are “stronger” than others, natural bullying will begin and proliferate if not stopped by a strong project manager. Culture, nationalism, and even religion can all get mixed in and sorting it all out requires both cultural sensitivity and management strength. I have found that a way to handle this is to create rules that help you sort through what is going on and encourage everyone into compliance. This approach should remove most barriers – the rules are the rules and everyone agreed on them ahead of time. Enforcing the rules is thus impersonal.
0 comments:
Post a Comment