Last week we talked about an alternate way of slicing OSS projects. Today, we’ll look a little deeper and include some diagrams.
The traditional (aka waterfall) approach to delivering an OSS project sees one big-bang delivery of business value at the end of the implementation. Many vendors still aim to deliver this way.
The yellow arrows indicate the sequential nature of this style of delivery. The implications include:
- If the project runs out of funds before the project finishes, no (negligible) value is delivered
- If there’s no modularity of delivery then the project team must stay the course of the original project plan. There’s no room for re-prioritising or dropping or including delivery modules. Project plans are rarely perfect at first attempt on projects as complex as OSS after all
- Any changes in project plan tend to have knock-on effects into the rest of the delivery
- There is only one true delivery of value, but milestones demonstrate momentum for the project… a key for change management and team morale
- Large deliverables / dependencies represent the proverbial Pig in the Python – each part of the project delivery team (eg design, build, test) is overloaded at one stage in the project then under-utilised for other stages (nothing else can get done around the big deliverable/dependency). This isn’t great for project flow or team utilisation
- Infrastructure builds and re-engineering the management network (and/or security of the management network) can be two of the big dependencies that hold up a project. Often, these projects are outside the direct control of the OSS project team. The OSS project team needs to find novel ways to demonstrate progress around these “pigs in the python”
- Vendors who build to this model also often aim to invoice against each phase because they indicate key project milestones. The only problem with this theory is that this is a bill against effort, rather than any real business value delivered. Clients tend to prefer to pay upon delivery of demonstrable business value. It’s easier to justify the spend to colleagues / stakeholders / sponsors within the business
The alternate approach seeks to deliver in multiple phases by business value, not artefacts or waterfall stages. It just requires some lateral thinking into what constitutes value to the business.
The example above uses the various environments as ONE way of slicing and dicing the scope. Whereas the PROD environment might require a large infrastructure build, it might be possible to build the sandpit (eg DEV/TEST) environment on existing hosting or even public cloud-based infrastructure. A public cloud might be a complete no-no in your organisation, but you could use set it up with sample / dummy data to mitigate any exposure risks.
Phased enhancements following a base platform build (eg Sandpit and/or Single-site above) – as indicated by Use-Case #1 to UC-N in the diagram – could include the following, where each provides a tangible outcome / benefit for the business, thus maintaining perception of momentum (sample assurance use-cases cited):
- Base build – for testing data structures, process flows, team product familiarity, scenario modelling, training, a base for document development (eg design docs), etc
- Additional event collection (ie additional collectors / probes / mediation-devices can be added or configured)
- Additional filters / sorting of events
- Event prioritisation mapping / presentation
- Event correlation
- Fault suppression
- Fault escalation
- Alarm augmentation
- Alarm thresholding
- Root-cause analysis (intra, then inter-domain)
- Other configurations such as latching, auto-acknowledgement, visualisation parameters, etc
- Heart-beat function (ie devices are unreachable for a user-defined period)
- Knowledge base (ie developing a database of activities to respond to certain events)
- Integrations – Interfacing with other systems (eg trouble-ticket, work-force management, inventory, etc)
- Setup of roles/groups
- Setup of skills-based routing
- Setup of reporting
- Setup of notifications (eg email, SMS, etc)
- Naming convention refinements
- Data modelling for further enrichments
- etc, etc
The latter is a more Agile-style breakdown of work, but doesn’t need to be delivered using Agile methodology.
Of course there are pros and cons of each approach. I’d love to hear your thoughts and experiences with different OSS delivery approaches.Read the Passionate About OSS Blog for more or Subscribe to the Passionate About OSS Blog by Email