How can you ensure that your road-map of projects stays robust and on target to deliver against your strategy? The one thing we can be certain about is that our road-map is in a constant state of flux. Schedules change, scope flexes, new projects are added and existing projects stopped. How do you help ensure delivery against your target architecture?
A good starting point is your knitting pattern but that only tells you that there is a potential dependency between two projects – it doesn’t tell you the nature of the dependency. A Functional Dependency Map (FDM) expands on the knitting pattern to give you more information about the links between your projects.
What does an FDM look like?
In this example, we already have two projects on our road-map: project 2 is enhancing your customer data store to provide support for corporate customers; project 1 is building some automation to create a customer record on demand. You’ve already established that there is a dependency between these two using your knitting pattern and the functional dependency map makes that explicit. Project 1 has a dependency on project 2 if your automation is going to be able to create corporate as well as retail customers.
Project 3 has just been initiated to provide online support for retail customers and part of that is to allow retail customers to sign up for an account online. Project 3 is dependent on the automated account creation being built by project 1 and, therefore indirectly, on the corporate customer build in project 2. You probably could have seen the first dependency quite easily, but the FDM also exposes these chains of dependencies. You can know see that any delay to the corporate customer build could affect your online retail customer build.
So, if that’s what an FDM looks like how do you use it?
Use case 1 – Get your projects talking to each other
If there are cross-project dependencies, then your analysts need to be talking to each other to ensure that their requirements and design are consistent and build towards the end goal. Also, your project managers need to be talking to each other about schedule – does the later delivery need to wait until the earlier delivery is in production or is a firm design enough to start with? Your test and deployment guys also need to be thinking. Should these be tested and deployed separately or can they be done together to accelerate value delivery for the business?
Use case 2 – Adjusting your road-map
Road-maps change for three reasons: addition of a new project; stopping an existing project; or change to an existing project (e.g. scope or schedule). Any one of these changes can have knock-on impacts to other projects on your road-map. The FDM allows you to quickly identify those knock-on impacts. If you’re stopping an existing project was that project delivering something that another project is dependent on? If an existing project is slipping what does that do to the schedule of dependent projects? If you’re adding a new project, what new dependencies are you creating?
Use case 3 – Program level risk and issue management
Most change delivery teams are pretty good at managing risks and issues at the project level. Where things start to get a little flakier is at the program level. We’re all aware of the concept of a critical path for projects but how often have you seen a critical path for a program? An FDM is not strictly a critical path for a program since it doesn’t include schedule, however, it’s quite close to one; and if you do find yourself using it for that purpose there is nothing to stop you adding schedule information to the FDM provided you’ve got a mechanism for keeping it up to date.
Clearly, there are other dimensions to all these decisions – not least code, environment and resource contention – but unless you have a clear picture of the functional dependencies on your road-map, you don’t have a robust road-map.