“Every new beginning comes from some other beginning’s end.”
This is where things get interesting. The benefits of an OSS are seen in daily operations, which go on for as long as the CSP does. Our focus is on the implementation of OctopOSS projects (finite time, specific deliverables) rather than ongoing operations (eg ongoing and/or repetitive tasks). Projects are defined as a temporary endeavour undertaken to achieve a specific result. This section describes the techniques used to deliver an OctopOSS to the desired outcomes.
Every project is vastly different, ranging from a minor configuration or application update through to a full-function OSS built from the ground up. As such, every OctopOSS project is bound to be unique and needs special consideration.
As indicated in Work Breakdown Structures (WBS), I start every OSS project with a WBS, mapping out the specific components, activities, objectives and responsibilities. A WBS can be created quickly and shared with the various stakeholders to give a starting point for further discussions regarding what the scope of the OctopOSS will look like.
PMI’s PMBOK (Project Management Institute’s Project Management Body of Knowledge) is a great resource for managing projects. The diagram below is sourced from the PMBOK and highlights the key planning activities that help to initiate a new OSS project.
All the items above are important project initiation activities, but the sequence that I typically follow is as follows:
- WBS [5.3] (as discussed above)
- Project Management Plan (PMP) [4.3], which includes stringent Change Management controls [4.6]
- Project Schedule [6.1 to 6.5] is based on the same numbering as the WBS in point 1 above
- Human Resource Planning [9.1] is then driven from the schedule in point 3 above
- Risk identification [11.2] is documented in a Risk (and Issue) Register (see sample in the Tools – Risk Register)
- The other activities such as cost, quality, communication, risk and procurement controls are all items highlighted in the PMP (see point 2 above)
- The other key activity that I look for that isn’t specifically identified in the diagram above is document / library repositories
- Depending on my role within the project, I often also seek to build a business case to succinctly highlight why the project is necessary
Dpending on the nature of the project, I then tend to utilise custom versions of the various templates such as:
- Requirements Capture & Vendor Selection
- Interface Assessment
- Naming Conventions
- Stakeholder Circle
Samples of these are included in the Tools section of the website
I almost forgot one of the most important aspects of project kick-off and that is the team-building exercise. It should be clearly recognised by all parties that the team we’re building involves the CSP, the vendor and any other party involved in the project. There can be no “us and them” mentality on a complex OctopOSS. Transparency of risks, issues, activities, responsibilities, etc are as essential during planning/kick-off as they are during the implementation.
We’ll cover the implementation aspects in more detail in Vendor / Project Implementations.