I was reading a discussion on the TP group on LinkedIn this week and the topic was ‘Do Consultants add sufficient value’. Great question and one that I would guess could be discussed endlessly. At the end of the day consultants can give the client what they are asking for, or what will actually help the business, which may not be the same thing.
Clients can ask for various things but my experience is there are always internal drivers that cause clients to need seemly random functionality. In most cases the ‘client’ is not one unified entity with unified objectives. As a matter of fact, I would say that it is the rule, and not the exception, that clients have competing internal wants, needs, objectives and most important of all--budgets.
Internal competing interests are not unique to Telecom or OSS, but because Telecom technology has evolved over time without eliminating the need to support legacy technologies many ‘silo-ed’ groups exist within Telecom organizations. OSS solutions impact many of these groups, but rarely do they only impact one group.
This situation is typically ignored at the start of an OSS project along with data considerations, vendor management, contract management and internal resource allocation.
All of it boils down to the reality that OSS projects can significantly ensure success or failure before the solutions are even selected by conducting the proper due diligence to identify the key internal operational ‘hot spots’.
These activities are almost never fully completed because they need to be completed before the project actually starts, or in the very early stages. Examples of areas to be evaluated or at a minimum managed tightly are:
1) Contracts. Agreements entered into with service and product vendors at the “executive level” can have disastrous effects if key operational resources do not understand them or have access to them.
2) Whose job is it to understand these contracts and what is each vendor responsible for delivering?
3) Are the contracts boilerplates, or are they specific to the project. Is the SOW detailed and is the Program Manager planning on using them during delivery?
4) Who is managing the vendors and what authority do they have? When finger pointing starts (100% guaranteed it will) who has final say to force vendors to deliver items they are pushing back on? Is it a steering committee, contractor, or unknown? This is one of the most poorly managed areas in OSS projects.
5) Data. Which data will be impacted. Who owns it? What political issues can you expect? Have internal agreements been put in place? Have internal timelines been agreed too?
6) Data cleansing. Data quality is always over estimated. It never meets expectations; it always is worse than you expect. Do you have enough internal resources prepared to assist with this activity? Have they been identified?
7) End Users. Do they understand the goals and objectives of the project? Outside of “super users”, end users are typically not actively engaged until the very end. Two weeks of training at the end of the project is not enough.
To ensure success start out on the right track. Empower your program managers with straight-line access to C-Level authority or an operational manager that sits above the silos. Depending on the program size, a few good program managers can help with these issues, but it is critical that they are OSS experienced. A generic PM will not be as effective.
These are not the only areas that are crucial to get right but If you can conduct the proper due diligence early, assemble the correct escalation authority, and empower your program managers, OSS projects can be delivered on time and on budget.