OSS Implementation Team

Two men looked through prison bars. One saw mud, the other saw stars.”
Proverb

The ability to focus on the stars, the fantastic outcomes of the project, is an essential attribute for all team members as they work their way through the complexities of the implementation of this OctopOSS.

The diversity of tentacles on your OctopOSS means that it is essential to create a multi-disciplinary project team to implement it. The team will be represented by delegates from many of your organisation’s business units, including:

  • Project Office
  • IT Infrastructure (including servers, LAN/WAN/DCN, operating systems, databases, middleware, high availability, client devices, etc)
  • Business Analysts
  • Marketing and Product
  • Sales and Channels
  • Customer Service
  • Network Infrastructure and Operations (including design and operations)
  • Finance and Accounting
  • Purchasing and Logistics
  • Human Resources and Training
  • Enterprise Performance
  • Testing and Quality Assurance
  • Data Scientists

Attributes of the Team
It goes without saying that team members should be creative, talented and ambitious. However, there are some other important attributes required to assemble a team that tackles the OctopOSS.

The project will introduce the need for teams of vastly differing skill-sets to collaborate and seek optimal solutions for the organisation’s greater need. The sheer breadth of scope means that no single person or group will hold all the knowledge or have all the answers. Every member of the team will have the responsibility to learn, but equally to teach and inform, ensuring that cross-domain needs are met. Information is power and OSS projects have no room for hoarding of information.
It is the journey of discovery and issue resolution that makes these OSS projects so demanding, but also so exciting and fulfilling.

The elegance of your team will come from developing a cohesive unit that will seek an outcome that looks beyond each member’s individual needs. Essential attributes of your team are:

  • Strategic Vision and Communication – The ability to create, share and focus on a common vision
  • Focus on The Greater Good – The ability to look beyond the needs of the business unit in deference to the needs of the project if necessary
  • Leadership and Motivation – The need for all members of the team to inform, engage and excite the people around them. Enthusiasm is infectious and is essential for overcoming the roadblocks that will arise during project implementation. There will be a need to energise individuals to produce high levels of performance whilst being willing to adapt to change
  • Promoting Diversity and Respect – The need to acknowledge that other members of the team will bring different skills to the project, but respect that they will not always have a peer-to-peer understanding of the knowledge or needs of others. Mattel’s Project Platypus provides a great example of the power of diverse insight
  • Problem Solving – The complexities and inter-dependencies of tasks can easily be used as an excuse for introducing delays. The team will need to be constantly seeking innovative ways of bypassing roadblocks and segregating dependencies
  • Conflict Resolution – Many roadblocks and differences of opinion will arise due to the complexities of this project, inter-dependencies and conflicting needs of the disparate business units. When combined with the vast in-flight learnings that will present themselves, many mistakes will be made and it will be easy to apportion blame. It becomes the team’s responsibility to resolve individual mistakes and ensure the project maintains momentum.

Team Structure
It is acknowledged that the need to build a project team with suitable expertise will almost certainly rob resources from the functional units that run the business. A Matrix project team structure will call upon the resources of these functional units. In such a structure, the Project Manager is likely to assume the role of coordinator and expeditor rather than authority over the resources.

It is the responsibility of the Project Manager to identify the experts that will be called upon and negotiate with the heads of the functional units to cover for the resource requirements of the project.
The conflicting needs of Functional Units versus the Project Team means that resource conflicts will undoubtedly arise during the implementation of the project. It is a common occurrence for OSS projects to stall as a result of experts having to attend to the Organisation’s operational needs. To protect against this a resource buffer must be planned in advance. The Project Team will also need to ensure that a “Project Champion” with authority over the functional units is fully versed in the needs of the project and enthused by the proposed outcomes. This Project Champion could be an individual (eg the Head of Operations) or a group (eg Executive Steering Committee).

The art of Project Management, the knowledge, processes, skills, tools, and techniques of managing a project is outside the scope of this document. However it should be noted that due to the complexity and cross-domain nature of OSS projects, it is easy for the project team to become strangled by documentation and meetings. It is the PMO’s responsibility to minimise meetings and documentation, allowing the Project Team to focus on delivery. They will also need to minimise delays in sign-off, authorisation and acceptance of deliverables.

However, this low-doc approach means that there must be an increased reliance on accountability by teamwork within the Joint Implementation Team rather than through contracts and documentation.

Vendor Team Involvement
Just as it is essential for the Organisation’s Project Team to be a cohesive unit, it is also essential that the Organisation’s Team and the Vendor’s Implementation Team becomes a tightly functioning unit, a Joint Implementation Team.
The Organisation’s Team will bring expert knowledge of their network, processes, corporate vision and business needs. The Vendor’s Team will bring expertise on their solution and the experiences gained from implementing OSS projects for other customers. The elegance of the final solution will be dependent on the innovative merging of both pieces of this puzzle by both organisations. The Vendor’s sales team will often claim that they can implement an OSS with minimal impact on the Organisation. However, they will never be able to understand the intricacies of how the Organisation operates and a sub-optimal solution will always result if the Organisation doesn’t assign suitable resources to collaborate closely with the Vendor throughout the implementation.

An us versus them mentality may ultimately be judged against contractual righteousness, but is likely to be detrimental to the outcomes of the project. The complexities and variety of in-flight changes present in an OSS project implementation mean that a contract will never capture all eventualities. Rather than creating an environment that causes the project to get bogged down in change management documentation, the joint implementation team will need to work closely together to best support the outcomes of the project. The attributes identified in section 13.2 apply equally to this joint implementation team.

Post-Handover Team
The Organisation will also need to consider whether a specialist OSS functional unit needs to be created for ongoing operations, taking over from the project team after the project has been implemented. This becomes primarily a question of the level of ongoing changes to the OSS. If the organisation is regularly implementing:

  • New processes or ongoing process refinements
  • Introducing new products or services
  • Changing functionality within the network
  • Ongoing phased upgrades to the OSS
  • Operations and Maintenance procedures that are too specialised to be undertaken by an IT Infrastructure team

The existence of these attributes means that a high level of OSS configuration skill needs to be retained and fostered within the organisation. In this case, it would be recommended that an OSS Functional Unit is retained after the project has been handed over to operations. The OSS Functional Unit would need to receive specific training that enables them to make application configuration changes.