Using program management to rebrand an organization over a weekend
Chief Executive Officer, BRISK Consulting
Introduction and Background
After acquiring 100% of a joint venture, a multinational banking corporation decides to rebrand the organization and launch its international visual identity with a big-bang approach. Country Management Committee (CMC) was hoping for a month-long transition, but thanks to program management, the award-winning rebranding was completed country-wide over a single weekend. This paper looks at how I used program management principles and practices to achieve this transformation. It also addresses the challenges, risks, and issues that threatened the success of the program and what we (the program management team) did to overcome them. The program ended up receiving a “Pan-Africa and Middle East Golden Eagle Achiever Award,” the most prestigious award within the organization, and the first time ever for a project team
One day, as I was working late in the office, I received a call on my desk phone. It came from the board room. The then Head of the Retail Business asked jokingly: “What are you doing in the office so late?” “Trying to make my projects work” was my reply. After telling me that it was a hopeless attempt, he asked me to meet him in the board room. When I entered, the entire Country Management Committee (CMC) — equivalent to the Board of Directors — was present. His first words were: “We need you to come to work tomorrow in overalls. Bring a bucket of paint and a brush. We're changing the name of the organization...”
The existing organization had been a longstanding joint venture between a local, government-owned bank and a multinational bank, ranking 7th worldwide at the time. A decision was made by the multinational bank to buyout the shares held by its local rival, transforming it into a fully owned subsidiary. The project seemed simple and straightforward in the beginning, but after some detailed analysis of the implications, it appeared to be significantly complicated. The organization had been overwhelmed with legacy processes mandated by the government-owned shareholder. These processes were all paper-based, which made the transition challenging. In reality, we were transforming the modus operandi of the business as well as changing the visual identity of the organization.
Benefits and Strategic Fit
During the CMC meeting, the impact of the re-branding was thoroughly discussed. The CMC wanted to send a series of strong messages to the market:
Tell their current and prospect customers that the organization is changing;
That the international hegemon is here, bringing its full power and all of its strengths to the local market by offering unprecedented propositions;
Reposition of the organization by adding a retail focus to its legacy by being the corporate bank of choice;
The same message was to be sent to the regulators and the competition, emphasizing to the latter that there is a new force to be reckoned with on the market.
In summary, the main benefit from rebranding was to achieve “the potential for a more aggressive approach to the market.” Other benefits of the rebranding included:
Brand positioning improvement, as the organization's name was still associated with being a quasi-state owned rather than a fully international one.
Multinational-standard market services and products with new top-tier prospect customers;
Improvement of staff morale by working for a multinational as opposed to working for a quasi-governmental organization;
Allow for coordinated and consolidated marketing with the multinational organization on the regional and international levels.
The CMC saw that the best way to deliver the above benefits was to use the big-bang approach. Re-branding the organization over a month at most and a week at best would be a dream come true. I asked them to give me a couple of days to develop a high-level program roadmap and see what could be done. I ended up sending them an email saying that I will rebrand the organization over a single weekend, using program management.
As with any transformation initiative, there were plenty of constraints. The most prominent of these were:
Avoidance of legal liability resultant from the inability to implement the change within the restricted time frames mandated by the regulatory authorities;
Avoidance of damage, harm, or undermining of the current corporate image resulting from risks that might emerge given the legal constraints;
Motivation of staff members who may be otherwise negatively influenced by the change of ownership;
Ensuring the awareness and commitment of staff to the change and its implications;
Enabling staff to entertain customer inquiries regarding the change of ownership;
Avoidance of disruption to business functionality during the course of the change;
Management of current customer relationships through informing them of the change, reasons behind it, and its impact, mitigating any doubts that may arise as a result of false assumptions or rumors;
Appropriate handling of sensitive items to undergo destruction.
Using Program Management
It was clear that the buy-out decision and consequent transformation initiative impacted all of the organization's departments to varying degrees. The buy-out decision also reflected the need for managing public awareness, customers’ announcements, and press releases. In order to best achieve the benefits, the entire organization needed to be aligned, with accurately defined projects running concurrently with very tight management of interdependencies, and very close monitoring of the incremental delivery of business benefits. This meant that program management was our only resort. A new program was born: Program Renaissance.
We, the transformation team in Egypt, conducted an in-depth impact analysis and identified all of the necessary change initiatives, translated them into projects, and integrated them under the program. This approach was welcomed by the CMC, as it provided them with a single point of visibility and the integration required for benefits realization as well as management of risks and interdependencies.
Immediately upon approval of the Program Management Charter, the Program Board was formed (Exhibit 1). It included representation of the Program's Senior User Group and Senior Supplier Group. Due to the organization-wide impact of the program, it was decided that the Managing Director should chair the Program Board. The Program Board then assigned me as the Program Manager.
It is noticeable through Exhibit 1 that there were two “Sponsor” Roles assigned on the program: the “Program Executive Sponsor” and the “Program Sponsor.” While this may be confusing and seem to be a duplication of roles, it was a strategic move that proved very beneficial for the program. The Managing Director was the only authority who could allocate resources to the program, resolve program issues across the organization, approve program and component strategies and plans, and make decisions across the organization that affected the program. For that reason, he was best fit for the role of Program Executive Sponsor. One challenge this presented was the actual availability of the Managing Director. He had the entire organization to run, and travelled frequently. As a workaround, a Program Sponsor was assigned. He received the full span of authorities from the Program Executive Sponsor by means of formal and referent power, and had more in-depth, day-to-day involvement in the program. Matters were escalated to the Program Executive Sponsor when they were clearly out of the span of control of the Program Sponsor.
Understanding the Implications of the Buy-out
As a first step to defining the amount and nature of work needed, a series of workshops were held with key function heads and potential project managers to carefully highlight the implications of the buyout. We needed to conduct this exercise to identify “what” needed to be changed and how. Exhibit 2 illustrates the initial list of deliverables, grouped under their respective functions. This diagram presents the high-level Program Work Breakdown Structure (PWBS); it was further decomposed to develop the entire PWBS, and component Work Breakdown Structures (WBS).
Breaking down deliverables proved to be exceptionally challenging. All of the deliverable groups were mapped horizontally across the organization's functions. For example, there were different MIS systems and screens that were used by more than one department, as there were multiple forms and templates to be replaced according to different functions’ needs. There was a very fine balance: if deliverables were omitted, then the ‘big-bang’ approach would have failed, and the benefits identified would have never been realized. On the other hand, if there were unnecessary deliverables produced, the program budget would have been unnecessarily expanded. The following strategy was used to overcome this issue:
Capturing the Requirements
The Program Executive Sponsor held a meeting with all function heads. In that meeting, all the new Visual Identity, Operations, and Process manuals were handed-out to their respective users, and the program was ‘informally’ introduced. It was agreed that the next day the program charter would be issued to all staff, and that a ‘Functional Focal Point (FFP)' (Exhibit 3) was to be formally assigned by each and every functional and branch manager to the Program. The role of the FFP was to:
Communicate and commit to Function's requirements (project deliverables) for all project phases.
Be accountable for Function's requirements in terms of:
Replacement and implementation quality control strategy
Compliance of deliverables to organizations standards
Deliverable Quality approval
Approve designs (where applicable)
Approve Quantities to cover quarterly orders
Communicate and actively participate in Staff Awareness campaign within their respective department/function/branch, supervise Communication
Act as a Communication Champion for this program at large.
Own, escalate, and resolve Issues and Risks related to function and/or its affiliated deliverables.
Provide information related to cost and time estimations as required by the Program Manager or Project Manager(s)
Acts as Benefits Manager for Function's requirements.
Represents Functional Head on Project Management Workgroups where relevant.
The FFP is to report to the Functional Head and the Program Manager following the standards of Matrix Organization structures.
Should the FFP be unavailable at any given point, the Functional Head replaces him or her.
Exhibit 3 below provides further clarification of the FFP’s role:
Architecture posed the biggest challenge to the Program. As evident from Exhibit 7 below, multiple projects had to run concurrently, with multiple interfaces and dependencies. At the time, the organization did not possess enough internal project management resources, and had already assigned a total of 63 personnel to the Program during its life span, which shot up to 122 on the launch weekend. Outsourcing was not an option due to the confidentiality of the initiative, and seconding resources from the mother company proved to be too costly. The workaround developed to overcome this challenge was that the Program Management Office (PMO) undertook all of the following activities. Project managers (who came from the functions) were rendered project expeditors, only in charge of execution. The tasks undertaken by the PMO on behalf of the project managers were:
Configuration management of all deliverables on all the projects.
Communication between FFPs and Project Leads (each party only communicated to the PMO). Justification: The FFP’s role, as depicted by Exhibit 3 above, needed to be re-iterated for every deliverable within their function/branch. And for every group of deliverables, the FFP would need to interface with a different project manager.
Overall Project Initiation, Planning, Monitoring and Control, and close-out Activities
Controlling Scope Creep
Once the requirements were submitted to the PMO, a dominant issue was realized. Functional staff compiled “wish lists” instead of requirements. For example, a completed requirements sheet received from IT would include mugs and wall clocks bearing the new Brand, while the one received from the mailroom suggested new MIS that automated random processes. This indicated a very high risk of scope creep.
The remedy to this risk was that all deliverables per function were allocated to the respective cost center of the function. The decision, once approved by the Managing Director (a clear manifestation of the need to have him as the Program Executive Sponsor), led functional managers to eliminate all non-critical deliverables from the requirements sheet as part of an expedited reiteration of Step 2 in “Exhibit 3 Role of the Functional Focal Point (FFP)” above. Furthermore, the PMO developed detailed product descriptions for each of the 1426 deliverables of the program, and obtained the necessary sign-offs from the Senior User Group to avoid any further scope creep.
Program Roadmap and Timeline
The Program Roadmap is illustrated in Exhibit 7. This diagram also shows how all projects were delivered in coordination to facilitate the launch over a single weekend. Most dependencies are illustrated on the diagram using arrows. Other, more subtle, dependencies have not been depicted to avoid cluttering the exhibit. After the deployment, administrative closure was conducted including a very detailed transition to business as usual (BAU). In order to streamline the latter, the staff awareness programs designed at the onset of the program included elements that prepared them for the transition. The early involvement of FFPs proved instrumental to this process, and as a result, only two weeks were needed for successful completion of transition. The following information is relevant to the exhibit:
The overall duration of the program from initiation up to the launch weekend was 6.5 months
Projects illustrated horizontally were conducted sequentially, and projects illustrated vertically were conducted in parallel.
Project bars are indicative of time/length of the project similar to what would be on a Gantt chart.
All “replacement” projects were not complete until their deliverables were received, consolidated as part of the “Material Resource Allocation” Activity, and “Dispatched, deployed, and installed.”
All “old” deliverables were dismantled, collected, and dispatched to the warehouses where they were either discarded or destroyed. This was an integral part of the FFPs’ role.
More details on the “launch weekend” are depicted in Exhibit 6 below.
Controlling Time and Cost Overruns through Aggregated Procurement
Another challenge posed by the Program was that there was one, drop-dead deadline. All deliverables needed to be produced and delivered in time to allow for “Material Resource Allocation.” The latter activity was simply the unpacking of all deliverables received from their suppliers, and repackaging them to meet the requirements of each function/branch. The packing lists were compiled by the FFPs and it was the PMO’s responsibility to ensure that all requirements were shipped to the FFP on the launch weekend. Failure to deliver the smallest deliverable would render the entire program a complete failure. A few of the risk threats encountered that would have caused delay of delivery were as follows:
Force majeure that led to supplier default
Supplier default due to lack of capacity/ability to deliver the numbers required on time
Inability of suppliers to access sufficient quantities of approved materials
The mitigation plan for these risk threats were as follows: As mandated by corporate governance of the organization, all procurements costing above a certain sum of money needed to be done through competitive bidding. By far, the budgets for every item (given the quantities) exceeded that threshold and therefore tendering was an integral part of every project. As the PMO we used this to our advantage. We developed a workaround by selecting three top-scoring providers for every deliverable and the required quantities would be split among them using preferential ratios. We faced yet another issue: as quantities assigned to suppliers were reduced, costs were increased. The remedy was to develop an annual blanket Request for Quotation for each deliverable, whereby the tendered quantities of each item were mapped to the annual demand of the organization. Successful suppliers would fix their prices for the whole year and would be awarded a Fixed-Price-with-Economic-Adjustment (FPEA) contract. They would be required to deliver the products in quarterly batches, starting with the batch needed for Program Renaissance (Quarter 1). The remainder of the contract was transitioned to BAU as part of the administrative closure process. Exhibits 4 and 5 below further explain this strategy. In addition to the above incentives on early delivery and penalty, clauses were applied to all supplier contracts as further assurance of on-time delivery
Integration – The Launch Weekend
As evident from Exhibit 7, the largest piece of work was that of the integration, when all deliverables were produced, compiled, and ready to be dispatched to the different functions and branches across the country. The mandate was to rebrand the bank over a single weekend, creating a big-bang approach and realizing the benefits listed at the beginning of this paper. Customers were well aware of this change. They had received letters, read about it in the press, and everyone was watching closely. An extensive advertising campaign announcing the new brand was scheduled to run for two weeks starting the second business day after the launch weekend. Being a high-ranking multinational, the organization could not close its doors for any reason even a minute early; no compromise was to be tolerated on customer experience. The stakes were high and the amount of effort was massive. We developed a detailed hour-by-hour project plan spanning 63 consecutive hours. Before we start discussing how the launch weekend was managed, please note that this program was conducted in Egypt, where the weekend is typically Friday and Saturday. The organization's working hours were from 8:30 a.m. to 5:00 p.m., which meant that we had from Thursday 5:00 p.m. to Sunday 8:00 a.m. to launch the brand.
Preparing for the Launch
Preparation for the Launch weekend took a full work week. A war room was set up at the organization's head office where all project and program staff collocated. All suppliers submitted their deliverables to that room and the PMO staff would invite FFPs to approve samples. Once all samples were approved, temporary labor unpacked the deliverables and repackaged them into department or branch designated crates as per the signed requirements sheets compiled by the FFPs at the beginning of the program. The temporary staff worked up to a deadline of Wednesday 5:00 p.m. Any delay to that deadline meant that they would have to work into the night to finish the packaging task. Another very important task during the preparation week was to dry-run all MIS, IT, and Telecommunication Systems, testing them for any fault in displaying the new brand or the new visual identity.
Thursday Morning (Hours -8 to 0)
This section explores the critical hours of the last day of the preparation week, leading up to the launch and how the different projects were managed in complete synergy:
Final acceptance of MIS, IT, and Telecommunication Systems by users and business
FFPs reported to the war room to receive empty crates, where they would package sensitive items designated for construction. Crates were numbered in a way that allowed us to identify each crate and trace it throughout the organization, tying it to department/branch and FFP for security reasons.
Starting mid-day, an external hauling company sent its trucks to the war room. Every truck was accompanied by a passenger car and the name of the destination branch was affixed to the windshield and rear window of both vehicles. The passenger cars transported the FFPs back to their branches along with temporary staff to help them out.
Trucks were loaded with the crates designated to their branch of destination and all official seals and stamps were officially handed to the FFP.
A similar exercise was done at the head office; the hauling company provided trolleys for each department, where their respective crates were mounted awaiting the launch.
By Thursday 5:00 p.m., all vehicles were loaded and everyone ready to dispatch.
The first and third columns of the above schedule were reiterated across the entire organization, for every department/branch. Only branches and office buildings had contractors working on signage, and IT works were done just at the head office and reflected across the organization. A different contractor was hired for every building, allowing for parallel processing of signage installation. Based on Murphy's Law, whatever could have gone wrong did go wrong. There were plenty of overruns that had led to slippage, but all were catered for and corrective action taken. Some branches were not ready until 30 minutes before their official opening time.
Including contractors, there were a total of 122 people working on the program countrywide during the launch weekend.
Conclusion - Lessons Learned
Lesson 1: Participatory planning works miracles
Ideas like the ones about procurement, integration, and others addressed above, as well as others not listed in this paper were developed in a collective manner. In many cases, the “Logical Framework Analysis” methodology was used in combination with tools and techniques including but not limited to cause-and-effect, decision tree analysis, the Delphi technique, and brainstorming. Every time an ideation or planning exercise was conducted, it was in a participatory manner.
The organization had very rigid governance structures that were in many cases not common to the local culture. This resulted in employees being very inflexible and adopters of a “we have always done it that way” attitude. To change their standard operating procedures for a Program of this magnitude, workshops needed to be held with diverse attendees: Top Management, Line Management, Project Management, and the executers of the work (subject matter experts). This combination — although resisted by the more junior staff at first — eventually brought about the following benefits:
- The idea that ‘it was okay’ to change standard operating procedures, as top executives were present in the workshops supporting and encouraging new ideas
- Estimates and suggestions were more realistic — they were made by the people closest to the work
- A sense of ownership and consensus was developed amongst the entire team.
I can strongly argue that without this approach to ideation, decision making, and planning, the program would have been impossible to deliver.
Lesson 2: Use preferential logic, in a preferential manner
In most of my presentations, I emphasize that preferential logic is a gift. You can make it work to your benefit by using it to develop the architecture and roadmap that best serve the delivery of your Program's benefits and to restructure the dependencies of your project so as to meet delivery deadlines. Conventional scheduling methods may not always serve the business benefit. How many times have you developed a project schedule using a conventional approach only to realize you were behind delivery date?
Lesson 3: Executive support gives you exponential power
Another lesson learned from this program is the value of executive support. This, in my opinion, is detrimental to project and program success. The bigger and more complex the program/project, the more crucial executive support becomes. Sometimes, project managers think that the involvement of executives would hinder their progress or limit their abilities. The lesson learned from this program is that on-boarding the right executives, and managing them and their expectations as key stakeholders was in fact an expeditor for the program.
Lesson 4: Integration of project performance into appraisals of functional staff makes them love your project
Because of the size of the program, as well as the fact that it required functional heads and their subordinates (FFPs) to provide their full support to the program, and in many cases, project expeditors were seconded from the business due to the lack of sufficient resources, it was agreed by the Program Board that any resource engaged on the Program would have a percentage of their appraisal based on their performance on the Program. That percentage of the appraisal was commensurate to the percentage of time they were allocated to the Program and/or any of its components. This proved beneficial in that resources took the task seriously, and gave it sufficient priority and devotion, as opposed to “doing it off the side of their desk.” This lesson learned led to two more very significant ones: Recognition works and Bonuses Work.
Lesson 5: Recognition works
The staff awareness campaigns included writing articles in the company monthly newsletter, by recognizing staff for their contribution to the program in these articles, morale was boosted, they were motivated to achieve more, and their peers were jealous — and wanted to make it into the next week's newsletter. Celebrating achievement (even if on a very small scale) with some pictures can get your non-project staff to go the extra mile.
Lesson 6: Utilize knowledge management for project delivery
When faced with the challenge that there weren't enough project managers in the organization to manage all of these projects concurrently, in addition to not being able to outsource, we had to resort to using functional staff as expeditors. Some of them had worked on projects before but never managed them. There was not time for formal training. We had to “chew as we run.” We gave them the confidence that the PMO would always be there to provide guidance and on the job training and any other form of support as needed. We encouraged Program Board members to convey the same message although informally. This led to a sense of trust, and reluctant expeditors were converted to motivated ones, as they felt the support, and were also learning a new skill that was well regarded by the organization.
Lesson 7: Partnering with suppliers works
With many of my clients, I have seen organizations take a ‘hostile’ standpoint with their suppliers. Mainly from the standpoint of “We are (Brand-name) and this supplier should be thankful they are working with us!” some people thought that they are actually doing suppliers a favour by awarding them business. On the contrary, it is their business, they do it best, and you (the buyer) cannot do it without them. Their success is yours and so is their failure. Aligning your suppliers’ goals with your programs, making sure they make a decent profit on the job (and not squeezing them out of every penny) and encouraging them to outperform the contract through incentives can help your suppliers deliver better, and help you meet — if not exceed — your project/program objectives.
Lesson 8: Governance can work for you
Just like many employees, I always thought governance was a curse. I never saw the value from having Forms to fill, processes to follow, and audits to sit through until Program Renaissance. As evident from the case above, I used governance to the benefit of the program, for structuring it to work across the organization, and for optimizing my deliverables and mitigating risk.
The most important lesson: You are only as good as your team.
Norwegian Agency for Development Cooperation (1999). The Logical Framework Approach, Handbook for objectives-oriented planning, Fourth edition, NORAD, Oslo, Norway.
Project Management Institute. (2008). The standard for program management—Second edition. Newtown Square, PA: Author.
Project Management Institute. (2008). A guide to the project management body of knowledge (PMBOK® guide)—Fourth edition. Newtown Square, PA: Author.
Project Management Institute. (2006). Practice standard for work breakdown structures — Second Edition, Newtown Square, PA: Author.
© 2013 Emad E. Aziz, PMP, PRINCE2P, CSSGB
Originally published as a part of 2013 PMI Global Congress Proceedings – Istanbul, Turkey