The project I’ve been working on the for the last few months is slowly grinding to a halt; the requirements are becoming vaguer by the day, with questions spawning more questions. In an organization that isn’t particularly pro-active these means that some decisions aren’t made until it is too late. This has recently been joined with a tendency to pull the senior engineers away from the project with no warning.
I started to look for a way to highlight the impact of these decisions to the programme management and stakeholders.
Talking to a couple of team members one of the things we realized is that we don’t have a good idea of who the team talks to and the influences on, and impact of, changes and delays to the system.If we don’t, how can we expect the programme team and business?
We started to map these out on the whiteboard and produced a few relationship maps to show how the team interacted with different parts within the organization. While quite team-centric the first map we produced shows how the team fits into a system of relationships and the complexity involved in what many feel is a simple process. The diagram is a very basic model, but further information was felt to distract from the information we have tried to show.
The relationship map won’t solve our problems of vague requirements and volatile stakeholder commitment; the hope is that it will impart a little more information on how the team interacts with other and help to explain the impact of delaying decisions on the project. Another suggested potential use that is to help pin down external stakeholders that the team can contact with questions, leaving them to work with the wider business.
John McFadyen 
Posted on March 11, 2010
0