So, you’ve got your list of projects, you’ve prioritised them for strategic value-add, you’ve scoped the program and projects to fit the change budget, you’ve arranged the schedule so that you can resource them all, you’ve re-arranged the schedule to avoid code and environment contention (that was a painful discussion with the top table wasn’t it?). You’re good to go right?
Whoa, Neddy, hold your horses for a minute.
What about your functional dependencies or conflicts? Do you know whether multiple projects are making changes to the same process, data, business unit or customer interaction? Do you know whether multiple projects are delivering incremental enhancements to any of the above and, if so, in which order they should you deliver them – one may be dependent on the other.
I can hear you now “But surely, I won’t know that until I know what the requirements are – and I won’t know what the requirements are until I start the project!”. This is true for a given definition of true. There is always a risk that project conflict on the functional level will emerge as projects progress. And, as we all know, rework and rescheduling is the biggest cause of project overspends by far. It’s also true, that functional conflicts can be predicted by using your capability model. If we can predict functional conflicts our stakeholders will expect us to do so.
Enter the “knitting pattern”…
|Project 1||Project 2||Project 3|
|Business Capability 1||*||*|
|Business Capability 2||*||*|
|Business Capability 3||*||*|
This is a very simple example but it should be enough to illustrate the principle. We have three projects on our roadmap making changes to three capabilities and we have three instances of more than one project affecting the same capability. Immediately we should be asking questions: Are the requirements for each capability change aligned/consistent? Are there any dependencies? At the next level down, are there likely to be code contentions?
Like most business architecture techniques, the knitting pattern doesn’t give you the answer but it does illuminate the questions. You need to understand what projects 2 and 3 are aiming to do with business capability 1 and make sure that your road map still holds up. Are the changes conflicting or are they supportive? If they are conflicting how are you going to resolve the conflict? If they are supportive, is there a logical order in which they should be delivered? Even if they are supportive, the first project needs to be aware of what the second project will be trying to achieve so that the design of the first project will support the delivery of the second.
The same goes for business capabilities 2 and 3.
This is one of the areas where a business capability model really comes into its own. The fact that business capabilities are logical (mostly) means that you can work with a relatively small subset of your business architecture assets. You don’t care which systems, which processes, which data, which channels, which customers, which resources… the business capability model alerts you to a potential conflict which you can investigate.
I call it a knitting pattern because once you have 50-60 business capabilities and 20-30 projects on our road map the spreadsheet/table looks remarkably like a “knit one/purl one” knitting pattern 😉
Once you’ve got your knitting pattern sorted you are then in a position to take the next step with your Functional Dependency Map.
Take away: A knitting pattern comparing your business capabilities against projects helps you validate your delivery roadmap.