pmStudent

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

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).

Continuous integration

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

Learning a lesson the hard way for the second time is a bitter pill to swallow.

It will suffice to say that my believe in continuous I&T has been strongly reinforced.  Partially due to my late arrival on one of my projects, and partially due to circumstances beyond the control of myself or my team, we were only able to do real integrated testing in the last few months.

We're still reeling from the consequences of not having started doing so much earlier.

Benefits of end-to-end testing, early and often:

1. Find internal interface problems early - In a complex software system, unit testing is necessary but not sufficient.  Those internal components need to be speaking the same language to talk to each other properly, and even if you are coding to the same set of specifications there will be difference in interpretation.  That is why integrated testing is so important.
2. Find external interface problems early - When your system interfaces with other systems built by other teams, this becomes even more important.  There are more changes for interpretations to be different when teams attend different discussions and assumptions get made.
3. Team building - I can't stress this one enough.  If your team is made up of people working in silos on their own little components who rarely throw them together and see what breaks, you lose out on so much beneficial communication and collaboration amongst your team.

So, even if you are not doing an agile approach, it's still important to do a build of your system every few weeks or once a month and see what breaks.  After all, the purpose of testing is to try to break what you've built.  Your team may be uncomfortable with this, especially if they are used to being able to polish their own individual pieces before displaying them to the world.

In this case, it pays dividends to be uncomfortable.  Discipline yourself and your teams to be comfortable with little, continuous simulated failures, so that you don't have to deal with a large, catastrophic failure on your project.

Share this with your network