I work in a project environment that consists of many project teams working on various systems that need to interface with each other. The interfaces between the systems can be the most difficult parts of the systems to manage.
Although we have interface specification documents (ISDs) and interface control documents (ICDs) some details of the interfaces still have problems.
So how do you make sure that project teams working together don't end up stepping on each others toes?
User stories by their very nature lend themselves to describe who needs what and why and this can apply to interfaces between systems very well. The format I use for user stories is the following:
"As (role), I (condition - need, do not need, expect, do not expect) (something), because (benefit). "
We also capture acceptance criteria to define how we know what 'done' looks like and a change log for reference when needs change. We just started doing this in my current project environment, and based on my previous experience with implementing user stories I am very confident these will help us be on the same page with groups and individuals outside our project team.
User stories are mostly useful as a foundation for discussion with the various stakeholders that you have, and make sure that you fully discuss the scenario and have documented what the decision was. On a project like mine, there are many situations where several ways to implement something exist, and it doesn't really matter which route we choose so long as everyone is on the same page.
Unfortunately, I have seen a lot of times in the past where one group thought that something was being implemented as A, and the group who was actually implementing it thought it was supposed to be B. User stories can help with these situations because doing them forces you to think through these situations and really clarify what A or B really mean and which solution we are going to implement.
They take a lot of the assumptions out of the process.
Open Communication Channels
It's also very important that your team members are empowered to go have the necessary discussions with groups outside your team, at any time their spider-sense is tingling telling them there may be confusion or different assumptions across groups. Everything does not have to go through the project manager. Many of these discussions will result in minor changes to the implementation that will not be a change in scope, schedule, cost, or quality.
I still ask my team to keep me in the loop, and they do a great job of this in our daily tag-up meetings when I ask the question, "What did you work on yesterday." In this way, we keep the whole team informed.
When changes do have potential impacts to the project's PMB (Performance Measurement Baseline) I am always involved. For each of these changes we need to do an impact analysis and weigh the cost-benefit to see if we really want to make this change through our CCB (Configuration Control Board).
One of the best things about an agile style process is that you end up doing a build and run through of your entire system from end to end every sprint. Although my teams are no longer doing strict time-boxed scrum, we are doing kanban in a modified way where we are still doing a build of the system every two weeks and running in from end to end.
In addition to running our own system we try as much as possible to get the most recent build from the other systems we interface with and build them as well. This is what I like to call continuous integration, and so far it's really helped us to identify the miscommunications that still occur even with good requirements, user stories, interface documentation, and all the other things that we try to do to make sure we don't step on each others toes.
Hey, if we're getting in each others' way I'd rather find out about it sooner than later.
On large projects, how do you keep your project teams from colliding?
|Share this with your network|