At the Beijing Olympics in 2008 both the US men's and women's relay teams failed to advance past the first round of the 400-meter relays. In both instances, the reason was that someone dropped the baton.
In track and field, the incoming runner must work hard to avoid dramatic changes in speed and stay in their predetermined part of the lane. In the nonvisual exchange, it is the responsibility of the incoming runner to place the baton in the hand of the outgoing runner. The outgoing runners position themselves in a stance that will allow acceleration and will allow them to see the incoming runner approach. As the incoming runner hits the mark, the outgoing runner turns forward and begins accelerating. At the predetermined point, the outgoing runner moves the receiving hand into position and leaves it there-keeping it as still as possible-until he has received the baton. The outgoing runner must avoid "fishing for the stick" and should keep the hand steady. The incoming runner can see the hand, and it is this runner's job to put the stick in the right place. But even Olympians seem to have trouble with these complex handoffs.
How many times in our project delivery, do we determine that someone "dropped the baton"? The issues we find in root cause analysis might say "code did not meet standards," "missed requirements," or "bugs not identified until after production release," but what this really means is someone did not do something.
Why? Generally I have found that the key reason is an improper handoff because of a lack of understanding or poor communication. The tester didn't cover this new piece of functionality in his test cases. Oops. The business requirements specification was never signed off by the business. Oops. The project manager failed to communicate the change in date to the client. Oops.
To avoid all these "Oops", I have a suggestion. And I cannot promise it will solve these failures, I can share with you that on projects where this activity has been completed, the handoffs are much crisper because communication has greatly improved.
My suggestion is that the project team takes the time early in the project to complete the RACI Matrix together. For those of you who haven't heard of a RACI (were you sleeping through that in your PMP class? J ), this is a document (usually in Excel) which defines for each project activity, who is Responsible, Accountable, Consulted, and Informed. It's a simply grid but it goes a long way in clarifying team members' roles and ensuring that everything the team needs to do in the project is taken care of. Some of you may be thinking - but everyone knows their role. They have a title and a bullet pointed list of things to do. How nice. And I'm sure everyone on your team read each other's role description in detail and know exactly how they can work together effectively too, right? Good luck with that.
We've started using the RACI on multiple projects at Alliance and I have seen the benefit of teams having open conversations about who is accountable, who the ‘doers' are and who needs to approve artifacts before they are complete.
My top 5 tips to facilitate the completion of the RACI are as follows:
- 1. Make sure you have clear definitions of each letter of the RACI. There are quite a few deviations on the letters. Whatever you agree to, make sure the team understands each letter before starting the exercise.
- 2. List all team members across the top of the matrix (give each one a column!) and make sure each person attends the meeting.
- 3. This should NOT turn into a project plan. List major tasks, deliverables, activities - but know when to stop.
- 4. Allow the (sometimes uncomfortable) conversations to happen between the team members - especially about who is accountable and responsible. What may happen is that the team realizes where they were dropping the baton. It's really important to determine who is going to take it. A person in the group may realize during the meeting that they were the person dropping the baton. Leave that behind. You are now establishing the new rules of the road.
- 5. Do this at the start of the project - once you know enough about the scope and deliverables to be effective. Revisit it from time to time - especially when you are starting to see deviation.
No comments:
Post a Comment