How can I collectively track application inter-dependencies?

Question

With varying teams delivering varying pieces of an overall solution it has become increasingly difficult to recognize when a given version of an application must be delivered with another application and different version that fits in to the overall solution. This same scenario surfaces where one application of the overall solution could be delivered prior to the other application but not the other way around.

A hypothetical example could be that there are 4 applications that make up an end to end solution of which serves varying user bases. What I'm struggling with is a way to track inter/intra dependencies across the applications in a simple and digestive manner that doesn't require a wealth of brainpower throughout the day to day tasks across the teams.

I've attempted to use tooling (SpiraTeam) as well as looked at a simplistic matrix within Excel however those have yet to solution the problem. I've also thought about making use of the version numbers themselves to quickly identify impact however that became cumbersome and not maintainable.

I'm looking for perhaps a one-off solution and or previous experience that does not require an entire process/paradigm shift to make this happen. Does anyone have any experience in effectively tracking inter-dependent applications and more importantly the release cycles of the inter-dependent applications within the Enterprise?

UPDATE:

To further elaborate, the dependencies are at varying layers within the applications. An example would be the front end of a given application, which talks to the applications back end which talks to yet another application via services. In this example the deliveries must go in parallel yet are operating independently on separate application versions. These undoubtedly spawn due to feature level deliveries however our current paradigm of versioning does not explicitly capture the feature within the version number itself making that connection more difficult. The plan is that it would be manipulated by the entire team which is in due part to the varying interdependence and each owner respectively being closest to that knowledge and interdependence. The end result is then a quick visual to identify that a given application can precede another version or maybe they have to go in parallel, etc... I have explored a simple matrix within Excel however it felt cumbersome since the version definition, versioning maintenance, etc.. happen within another tool. The problem with the tool is that it does not allow inter-connectivity across projects (applications) which would alleviate this issue at the point where I feel it should be solved.

Answer 1

This is an architecture/configuration management problem, not a PM one. Obviously there is a PM impact, so you need to address it.

On projects I've worked on I've found the following helps a lot:

1. Baseline your working code. (What versions of the 4 applications are known to play nice together?)
2. Lock down the interfaces/shared resources between the applications. Not a code freeze, but make sure that any changes are carefully vetted by all teams not just the two that interface, because...
3. Brainstorm your edge cases. I've had a problem where an xml message created in java was being sent to a C socket program, the empty nodes got populated with nulls, and the C program would truncate the message. In this case both teams thought they knew what to expect/provide, but missed an edge case that was dependant on the Java/DB interface. Java asked for something, the DB didn't have it so provided a null.
4. When you get a new version of one of the applications, do a complete regression test with it and the other applications. Do a limited release with it, if possible, and then update your baselines to include the new app version.

Answer 2

TL; DR

Think techniques, not tools. Tool recommendations are always off-topic on PMSE. However, there are several techniques that may be of value from a project management perspective.

In general, you have two main approaches:

1. Decomposition.

   A traceability matrix or dependency graph can be useful in decomposing tasks.

2. Verticality.

   When features are too tightly intertwined to decompose into linear dependencies, then you must treat them as vertical slices of work.

Potential Techniques

Here are some potential techniques that may provide project or scheduling breakdowns of sufficient granularity:

1. Build a traceability matrix, which is useful for tying complex requirements together.
2. Develop a Mikado diagram, which is essentially a directed acyclic graph of dependencies.
3. Follow a "vertically-sliced feature" approach, in which a full-stack feature is described in terms of functionality but the implementation is left to the discretion of the cross-functional team that is building it. (NB: This is the approach used by most agile development teams.)

There are certainly other approaches as well, but the techniques still ultimately fall into either the decomposition or verticality categories. If you are unable to make headway in either category, then it might be useful to take a step back and rethink why your project is so tightly coupled.

Overly-coupled requirements are a common project problem, but the root cause is often a design or planning failure rather than an unsolvable technical problem. However, your mileage may vary.

Answer 3

It sounds like your dependencies are basically modules or layers within a single application?

Truth be told, I'm not a big fan of "heavier" digital tools, but I think that if you're looking for something that will natively tie change sets to versioning to dependencies and team members or projects, you will need to look into something like modded JIRA or MSProject/TFS as the others have suggested.

Personally, I have found success with simply focusing on extremely high visibility over specific tool functionality - it's very hard not to coordinate well when each group's backlog/sprint chunking, progress, current risks and dependency items are cards up on a big wall in the team(s) area. :)

Answer 4

Some of the other answers provide some good suggestions from a project management standpoint. However, in my experience, projects dependency management should be only supplemental. Most of the heavy lifting in this area should be at the technical level.

Because this is the PM board, I don't want to get into too many details, but you could take this back to the team and if they're unsure how to accomplish it, there are other great stackexchange boards for programming that could give extensive information on these topics.

The two areas in particular that will make the biggest impact are:

Code Repository: Effective use of a code repository, especially with a good suite of unit tests, can create builds where you know all of the pieces are working properly together without taking too much time away from the team's development cycles.

Object-oriented Principles: I try not to be dogmatic about this, but staying in the spirit of object-oriented programming (I like to point people to SOLID principles as a start) goes a long way to decouple parts of the application and allow the application to grow without asking the PM to control every small step forward.

Of course, some teams don't really like having a project manager tell them to improve technical practices, so you may have to approach that delicately.