IT Program Management for TELCOS
Summary
Today’s Telecom Services companies are working in a very competitive environment. In order to sustain themselves, they need to constantly launch new products and features. Thus the success of their IT does not lie in executing a Single Project successfully but having a delivery eco-system which ensures that they are able to launch new product in a very efficient manner. This document will analyze key factors and trade-offs that are critical to achieving delivery efficiency in large program undertaken in a Telecom focused organization. This will also suggest the methodology to align the organization structure and key practices to achieve delivery efficiency. Delivery Efficiency is basically a measure of how efficient your IT systems are in terms of enabling a new product launch into market and supporting/enhancing the existing products and business by maintaining those systems
Organization Structure
Organization structure is an enterprise environmental factor which can affect the availability of resources and influence how projects are conducted. Organization structures range from Functional to Projectized, with a variety of matrix structures between them. Table below shows key project related characteristics of the major types of organization structures.
Matrix organizations are a blend of functional and projectized characteristics. Weak matrices maintain many of the characteristics of a functional organization and the project manager role is more of a coordinator or expediter than that of a true project manager. Strong matrices have many of the characteristics of the projectized organization and can have full-time project managers with considerable authority and full-time project administrative staff. While the balanced matrix organization recognizes the need of a project manager, it does not provide the project manager with the full authority over the project and project funding.
At the opposite end of the spectrum to the functional organization is the projectized organization. In a projectized organization, team members are often co-located, most of the organization’s resources are involved in project work, and project managers have a great deal of independence and authority. Projectized organizations often have organizational units called departments or functional Groups, but these groups either report directly to the project manager or provide support services to the various projects.
Though from an individual project perspective it is always better to have a Projectized organization as It gives a project/delivery manager complete control over the team and hence improves chances of project success but in an industry like Telecom where domain skills play a very crucial role, if the resources are not aligned to underlying functional/technical/domain area then the organization will lose its competency over on the technical/domain skills and will be at disadvantage to competition.
Hence it is recommended for the organization working as telecom service providers to follow Matrix organization structure. Within Matrix, it could be a weak matrix or balanced matrix depending on the other environmental factors of organization. Also, for the highly critical project or critical phases of the project, the teams may be co-located to do a dedicated time bound workshop. Workshops also help getting required resources’ attention to the critical project/phase thereby giving impetus to the overall delivery. This will give the project required characteristics of strong matrix/projectized environment for the limited period where it is required.
Below is an extension of the Matrix organization with various functional groups and their roles defined which the organizations can adopt. It defines various groups and has attempted to balance between aligning the groups to underlying functional domains thereby protecting the skills and competency; yet ensuring the projects and programs caters to business with minimal overheads and in agile manner.
Delivery Cycle
There are currently various delivery methodologies for executing large programs for e.g. — Waterfall, Iteration, and Agile etc. Considering that in the telecom focused organization which follows a weak or balanced matrix structure, it is prudent to follow a methodology which inherently supports interaction and feedback at a high frequency and Agile stands out in that aspect.
A typical project execution by Agile (SCRUM) refers to dividing the work into multiple stories and taking a set of stories in 2 weeks SCRUM. Here it is imperative that we have these in place –
1) Delivery Cycle or delivery engine that keeps churning out the stories.
2) Priority Management — To feed into delivery engine what needs to be delivered. It also ensures that the requirements presented into delivery engine are specific, atomic and has clear business benefits.
3) Change Management — To manage the scope creep
4) Quality Management — To ensure that key quality parameters are tracked at program level and improved upon
5) Program Management — To monitor the delivery process and propose and implement changes to improve the delivery efficiency.
Apart from above, we also need an architecture board to sign off on all architectural changes and provide the architectural steer to the whole program.
Let’s discuss all these in bit detail
1) Delivery Engine — As there are multiple teams involved with each having defined set of responsibilities, below process defines the life cycle of a requirement till it gets deployed on production (live) and also the teams that are responsible for working during each phase.
After each release cycle Delivery Hub collects the key along with other groups conducts a brainstorming session with other groups to reflect on what went right/wrong and feeds into Program Management Office (PMO) for process changes.
2) Priority Management — It is imperative to have a process of right prioritization so that the resources work on what delivers highest value for business. Though it is obvious that prioritization should be done of the artifacts that deliver direct value to business or in other words, it should be done for the requirement artifacts and not of any process/design artifacts but what is missed is quantum of the artifact that should be prioritized.
Imagine there are multiple programs running and each program would have quite a lot of requirement artifacts waiting to be delivered. If the requirement artifacts taken into delivery are too chunked then delivery overheads would increase significantly. However if the requirement artifacts are too big to be delivered into a release then also there is a significant overhead in terms of working the risk of putting untested code into live, putting the code in dormant manner[which might not be always possible] or doing a roll back of the code followed by significant regression testing. Hence it is imperative that organization follows –
a) Sizing methodology of their requirements — The sizing of requirement can be done using various estimation methodologies (Use Case point, Function Point etc.) or organization can come up with its own sizing technique considering the local environment factors.
b) Establishes a sizing baseline — The PMO should be collecting the data from each release as what was the average size delivered; was there any requirement that needed to be postponed to next release with reason. Ideally the size should increase as the delivery engine becomes more efficient.
c) Recommends the right size of the requirement to be taken into delivery — Based on the sizing data across the release, a recommendation can be made on what is the right size of the requirement considering the release cycle. If it turns out that the right size of the requirements do not deliver significant business value in most of the cases, then the release cycle timelines can also be looked into.
d) Have a quality gate in place to ensure that requirements taken into delivery are right sized. — This quality gate can be put once the design is complete and individual functional teams start to develop the stories. It should also consider the internal dependencies of the requirement to arrive to conclusion.
While doing prioritization it is important to consider what is being prioritized. Is it a use case, a user story, a bunch of user story, a bunch of user case?? Also, while prioritization it is important to consider priority between multiple programs.
Let’s consider that requirements are captured in the form of Use cases which are specific, atomic and describes clear business benefits. All the programs can suggest the priority of their use case to the Prioritization board and then prioritization board can decide on the priority across the use cases from all programs. The use cases dependency can be taken into consideration for assigning priority as well. So the priority of a use case can be XX.A.BB
Where XX shows the Release for which it is prioritized.
A- is a number 0–9 which defined priority based on the guidelines below.
BB is the relative priority considering dependency.
These guidelines can be used to assign priority [A].
Priority 1. We really Must
ONLY regulatory, legal, safety, major financial penalty, needed to stay in business.
Priority 2. Should
High revenue/revenue protection (>XYZ million as defined by organization)
High cost avoidance/ cost reduction (>abc million as defined by organization)
High cycle time reduction (>X day as defined by organization)
High EBITDA improvement (>abc million as defined by organization)
High Right First Time (>X% as defined by organization)
High Person Involvement reduction / avoidance (>N Individuals as defined by organization)
Priority 3. Could
Medium revenue/revenue protection (<limits mentioned by organization>)
Medium cost avoidance/ cost reduction (<limits mentioned by organization>)
Medium cycle time reduction (<limits mentioned by organization>)
Medium EBITDA improvement (<limits mentioned by organization>)
Medium RFT (<limits mentioned by organization>)
Medium PI reduction / avoidance (<limits mentioned by organization>)
Priority 4. Would
Low revenue/revenue protection (<limits mentioned by organization>)
Low cost avoidance/ cost reduction (<limits mentioned by organization>)
Low cycle time reduction (<limits mentioned by organization>)
Low EBITDA improvement (<limits mentioned by organization>)
Low RFT (<limits mentioned by organization>)
Low PI reduction / avoidance (<limits mentioned by organization>)
Priority 9. Not prioritised
New to list, not prioritised or insufficient benefit quantification
3) Change Management — The Change Management Board validates each prioritized requirement if that can be considered into current release or needs to be moved out of scope. It is responsible for →
a) Base-lining the scope for a release at the beginning of release
b) During the release approving the change.
c) For each release measuring the scope change and base lining it v/s previous release. It can be a simple number say — ‘scope creep factor’ defined as [total requirement moved out + total requirement moved in]/total requirement delivered. This factor should be monitored across releases/programs with an aim to bring this down.
d) RCA into reason for the scope creep. RCA can lead to defining quality gates which can be used before base lining the requirements.
4) Quality Management — The Quality Management board should measure following parameters across the program and update into the process baseline. Organization can take up any sizing parameter for requirement depending upon its maturity for e.g. Use case point/Function point/ etc.
Let’s take for e.g. that 1 organization is using Function Point as sizing parameter.
a. For a particular release, what is the defect density for each functional group i.e. Defects/FP — How it is comparing across functional groups and how it is comparing to across different release within the same functional group. Often organizations start comparing the absolute defect numbers instead of defect density. Absolute defect number does not give anything regarding the quality and should be avoided.
b. What is the cost for delivery per Function Point i.e. $/FP.
c. For a release what is the overall FP delivered compared to last release. Positive change should be attributed and mapped to factors or initiatives taken for productivity improvement. Negative change should be RCA’ ed and appropriate action taken.
d. Scope churn and reason for scope churn — What factors led to the scope churn. This should be RCA’ ed with aim to reduce it release on release basis.
e. Average size of the requirement and delta from average size. This can be used to find out what is the right size of the requirement [use case/user story etc.] that should be taken into release. If this size doesn’t deliver significant value to business, then it’s time to relook at the release cycle.
5) Program Management Office — The PMO works with other team to monitor the delivery process and capture key parameters relating to scope creep. Quality, Cost and Throughput and analyses them and propose process changes so as to improve delivery efficiency. They also propose various release cycles and durations and ideal size of the requirements and number of requirements to be taken into each release. It also monitors other groups and how efficient they are functioning.
Best Practices for Running Large Programs
1. Testing Team Involvement — The E2E testing team should be involved during the cross functional design phase. However, it is imperative that the handshakes within testing team are minimal and wherever possible, the person writing the test cases and the one executing it should be the same. Also, as there will be lot of regression testing needed in each release, it is prudent to have some degree of automation done for basic order journey of each product. This will also help create assets faster and reduce the time and effort needed to do regression testing. As the automation also comes with additional cost and overhead, only the basic product journeys that would need to be regressed in each release should be automated.
2. Right Sizing of the release cycle — IF the Release cycle is very long then it will take lot of time for business to see the requirements developed and deployed into live. If it is too small then nothing worth providing business benefits would be able to deliver in a single release and at times the requirements [use cases/stories] would need to be pushed from one release to another. This will bring additional overheads and frustration to the people involved. Hence it is imperative that PMO monitors the size of release cycle by observing the average size of requirement being delivered, requirements that are being de-scoped due to insufficient release time and also whether the requirements are delivering tangible business benefits. The PMO should define the release cycle and also propose the right size of the requirements taken into delivery/release cycle.
3. Trade Off between extra resources and delayed launch — The capacity to deliver requirements would depend on (apart from other organizational environmental factors) the number of resources that are there in the underlying functional groups. If there are lesser resources in the group then at times the requirements will have to be deferred to other groups which will have an impact on product launch or customer experience; at the same time if there are more resources then at times they will be under-utilized. It is futile to achieve that perfect balance. As organization embrace offshoring, the cost of keeping an extra resource at offshore is insignificant as compare to the overall costs required for the functional group. Hence functional groups can keep 10% extra resources based out of offshore. This can be utilized to increase automation and bring in improvements within the functional groups and whenever there is a need they can work on the business critical requirements.
4. Prioritization — Before the stories are taken into prioritization it is important that all the requirements are validated whether they are clear enough to be taken up for design and also if they are really required as per the priority mentioned. Also the requirements that are required for Day 1 product launch should be separated and presented to priority and not mixed with the requirements that do not form part of minimal product set launch criterion. If the requirement Triaging happens before prioritization, then the above problems can be addressed. The triaging process will also ensure that the requirements that are being presented by CIO are atomic, specific and with clear business benefits.
5. Testing on integrated environment — Often it is observed that when the components are dropped into End to End testing environment, there are integration issues found and due to which critical time of all the involved teams [E2E testing, Delivery Hub, Functional Groups etc] is lost and often the requirements are pushed to next release. Hence the key components of the stack should be identified and provided a separate environment to integrate before pushing the code to End 2 End test environment. Here it is noticed that we are not asking the components to do entire testing in the integration environment as that would be time consuming and would entail high costs; a basic sanity testing of happy path would be sufficient. This would keep the integration testing costs down and at the same time would ensure that we do not encounter lot of blockers during the end to end testing. The cross functional design team within the domain delivery group can facilitate this integration testing.
