Confession of a Program Manager(Part 1)– Inception Phase

On a broad level every transformation project goes through the following phases

1. Inception – This phase deals with the selection aspect and the Requirements gathering
2. Elaboration – Elaborating the requirements to second level such that a Design can be put in place and Build to take place to suffice the identified needs.
3. Install & Testing – Hardware, software installation followed by testing starting with but not limited to Unit Testing, System Integration, UAT, Regression, Performance, Vulnerability and penetration, Security, Load & stress testing, Certification and so on.
4. Dress Rehearsal & Go-Live – the penultimate and the final stage of the transformation
5. Stabilization – The most treacherous period after go-live as most of the project team is dissolved & functions are handed over to BAU operations team.

Inception Phase:

I feel that the stages suggested by Bruce Tuckman in 1965 for group development are essentially applicable to the project phases too.

Tuckman suggested Storming è Forming è Norming è Performing as the 4 stages of group development. The Inception phase is where the storming and forming begins, gradually progressing to norming and Performing. An experience program manager would expedite some of the steps to take it to a stable Performing stage as quickly as possible. There are a number of challenges encountered during the inception phase.

• Stakeholder identification: During initial days of the Inception phase project manager is still trying to figure out the teams involved, their roles etc. Doesn’t matter even if the project manager is from within the organization – as the nature of the transformation project is unique and most importantly the people involved have not gone through a similar journey. Getting stakeholders together for important decisions and progressing as planned is a difficult task. Many a times the steering committee level meeting is called but it ends without substantial outcome of decisions.

A seasoned program manager should be able to handle such situation with better success.

• Never ending workshops: During the initial days of requirement gathering teams have euphoria to come to the table and add their requirements. The problem is at times such requirements are not in sync or even worse contradicting to each other. Multiple business teams must talk to each other and come up with a validated requirement. An experience project manager will ensure this activity and put controls in place to make it time bound outcome activity.

Sometimes departments are kind of late coming to the table thus further pushing requirement closure timelines. It’s difficult to manager such things as they do not report into the sponsor or the project initiating team but are a party to put some obstacles on the road.

• Tactful vendor management: I have come across this situation a couple of times, where in sometimes vendors will try to push timelines and efforts by stating the requirements are a customization. Where as in reality it could have been just a setup or a parameter tweak. Identifying the real change requests or a deviation from base product is skilled job to be performed. Top management never likes to hear that product cost + customization is going to make it double the initial thought cost.
• Lack of existing design / documents: Core systems and cards management systems usually stay for decade or more simply because of the effort and cost involved. Also it evolves and get complicated over the year due to adding layers and enhancements. It’s a dream to have all those changes properly documented and available at the beginning of the transformation program. Ground reality is it seldom happens. It’s up to the skills of a project manager when to involve the system architects streamline this process and get it done in planned time.

Business teams expect that the old system behaves in a certain way and write down the requirements accordingly, but turns out due to lack of old system documentation, or changes applied doesn’t really happen that way L. Thus making another iteration to fix the requirement.

• Managing teams with different attitudes: Over the years I have faced some tough teams who would not want to budge from their requirements or timelines even though it might sound trivial in the big picture of the transformation project. Teams rightly become rigid and process driven but it shouldn’t get pushed to such an extent that the transformation project timelines are at risk. Tactful handling of such groups is very essential for project success.
• Getting team combination right: One of the absolute must is to have a full time core team assigned to the project. As a program manager it’s a non-negotiable thing and I would recommend this must be fought with tooth and nail if need be. People will come and go during the course of project but making the team combination work in unison is what matters!

Usually I have seen the workshops being conducted in person to fast track capturing of the requirements, but getting the right business process owners and decisions makers to the table will ensure this happens as planned.

• Fear of CHANGE: One of the biggest challenge I have seen is not technical or functional in nature but the fear of change in people’s mind! They are afraid of the changes; some think will it result into job losses. Whereas other think it a waste of time to change the system as the old one is refined over past decades. Some are simply comfortable working in a specific way and resist learning new things L
• Estimating with right approach: Towards the end of the inception phase Project charter get refined, project timelines gets firmed up and Integrated project management plan is an absolute must outcome. It’s easy to take the longest timeline and suggest that only this work, but believe me no matter whatever longest timeline you chose at the beginning it will be always challenging to achieve it. In fact, my opinion is to keep it at an optimal timeline possible to get over with the project in quick time into stabilization phase.