Program Management in Difficult Environments: How to turn risks and constraints into advantages

Program Management in Difficult Environments: How to turn risks and constraints into advantages By: Jeff Toppall, PMP, and Bob Meyer, PMP, Sapient Government Services

Š Sapient Corporation 2012

1

Program Management in Difficult Environments: How to turn risks and constraints into advantages

Program Management in Difficult Environments: How to turn risks and constraints into advantages This white paper describes successful program management outside of the defined methodology and application of best practices. Great program management requires understanding the challenges created by human complexities at the organizational and individual client levels. A client’s politics, personality, organizational structure, and leadership qualities affect the ability of a Program Manager (PM) to perform efficiently and produce quality deliverables.

We will examine situations where the barriers to success lie not only in the program’s complexity but in the risks and constraints imposed, intentionally or not, by the client. By learning how to manage in these difficult environments, you will be able to mitigate and transform obstacles into positive value to benefit your client and team’s success.

Program management at its core is about relationships.

We will highlight six program management challenges often found in difficult client environments. Our best practices will focus on how to achieve positive outcomes using tactics that are not in the PM manual.

• Executive direction does not translate to daily priorities • Frequently changing client PMs requires shifting strategies • The loss of the System Champion • Overall technical solution is supported by multiple teams, each with its own list of priorities • Lack of control over the development environment

2

• Project plans are subject to frequent changes due to external dependencies, but the client does not support an Agile methodology for incorporating change CHALLENGES AND MITIGATIONS CHALLENGE 1: EXECUTIVE DIRECTION DOES NOT TRANSLATE TO DAILY PRIORITIES Executive management must effectively define organizational priorities with the working groups that support projects in order for them to prioritize resources and remain on schedule. In some cases, executive messages do not always trickle down to the project’s support professionals to be incorporated into their day-today functions and priorities. As the result of a disconnect in priorities, projects can easily progress at a slower pace, risking delays.

Within information technology departments, there can be natural conflict between teams. As an example of dissimilar priorities, an organization could have an operations team focused on keeping existing solutions working and an engineering team tasked with delivering new functionality. The key mitigation strategy in these difficult situations is to encourage team collaboration and support. For example, instead of reiterating the executive’s priorities, it may be more effective to find ways to convince project teams to“buy into” the overall project and reset their priorities. This approach will greatly increase the likelihood for the project’s success.

• Build strong professional relationships with technical professionals that have hands-on skills to accomplish the required tasks: In order to establish and build

© Sapient Corporation 2012

relationships with these individuals you must become more than a name on an email or a voice on a conference call. These individuals may have some freedom to prioritize their own workload, so stop by their desks and get know them as people, not just resources.

• Get to know their manager, and how much leeway her staff has: Some managers are sticklers for process, while others are more focused on results. Understanding the management style controlling a given team is a key element in managing communications channels when trying to get something done. If a PM cannot directly task external resources but the work still needs to be done, the PM needs to understand how best to work within the existing organization to get resources assigned and how they will be held accountable.

• Say “Please” and “Thank you” frequently: This is particularly helpful with people who do not often receive expressions of gratitude from those asking for their time or assigning them tasks. If someone has an hour of unscheduled time and three 30 minute tasks to accomplish, building a personal relationship with a touch of gratitude helps ensure your 30 minute task will be accomplished first.

• Be specific with questions and detailed with responses: Provide people with all the information they need in order to make decisions in a timely manner.

Incomplete paperwork makes the PM appear unable to provide the information being requested or indifferent to the impact of not doing so. Forcing someone to read several days worth of an email trail to understand the context of a question wastes time and risks that person missing the key item to be understood or accomplished.

Providing specific details and instructions empowers people to be more productive and builds a favorable impression of a project team.

• Be persistent, but never pester: Even if people cannot be directly tasked by the PM, they must be held accountable for work assigned by their management which impacts the project. Polite and professional communications with people who support the project sends the message that doing nothing is not an option.

CHALLENGE 2: CHANGING CLIENT PMs REQUIRES SHIFTING PROGRAM MANAGEMENT STRATEGIES Client behavior matters tremendously as it impacts the carrots and sticks that can be used to move that client in a productive direction. During one project, the lead client PM changed three times within 14 months, and each had a very different approach to the project. The three project leads on this project have been described as: • Laissez-faire but a committed advocate: This is the ideal PM for Sapient. The Sapient team attempted to resolve problems before escalating them to the client lead. In this case, the client PM was very willing to intervene and make decisions when necessary because he knew all other alternatives had been exhausted prior to seeking his involvement.

• Painfully proactive: This PM was the opposite of the first example. He insisted on being involved at all levels of the project. He turned routine discussions and negotiations with other organizations into confrontations. He alienated these teams and damaged the brand of the delivery team within the client organization. Substantial and sustained fence-mending with the teams upon whom we depended for support was an ongoing necessity. We had to reassure them that we were not responsible for the PM’s opinions and actions. A very honest and blunt conversation with this PM, and his management, about the effect his style had on the project was necessary to prevent even more harm from occurring, but didn’t solve the basic problem.

• Minimally involved: The third PM knew that his assignment was temporary, and did not particularly care about the project. Despite repeated attempts to get substantial guidance or assistance, the PM showed no interest in providing the leadership necessary to move the project forward. The Sapient team had to operate under the assumption that such leadership would not be forthcoming. As a result, we went behind, around, and above him to get things accomplished. We mitigated the risk of working around our own client by ensuring he was kept fully informed in writing of all meetings and communications. A defensive strategy of documenting our communications, while proactively solving problems, was our only option.

This works best when teams are already empowered with the information they need to succeed and a positive relationship has been built with team members.

© Sapient Corporation 2012

3

Program Management in Difficult Environments: How to turn risks and constraints into advantages

CHALLENGE 3: LOSS OF THE SYSTEM CHAMPION Change is hard and often meets resistance in ways outside the control of the delivery team. Budgetary, political, and cultural resistance to change represented by new initiatives requires the leadership of an executive level system champion. When this champion is lost, the project often loses momentum, effectiveness, or both. While the PM cannot replace the system champion, there are strategies available to mitigate the loss.

• Do not let offhand comments about future direction go without clarification: If the success of the current project is at risk, every opportunity should be explored to gain intelligence about the client organization’s future direction. This knowledge can be used to salvage, repurpose or rebrand the work. Status reports from other projects, policy announcements (official or off-the-cuff), organizational changes, and executive communications on priorities provide information that can help a project manager sustain momentum in the short term or fit the project into an organization’s long term strategy.

If a system champion is not available to remind the client why the deliverable is important, the entire delivery team must be enlisted to perform this function and the PM has to take the lead in this endeavor. The risk to the delivery team is finding out the deliverable has become irrelevant.

The mitigation is to constantly search for additional justifications for the project, redefine the deliverable in ways that are relevant, and sell the client on that vision.

• Constantly manage expectations of all stakeholders: Without a system champion, the external teams upon whom your project depends are less likely to move the project up their priority list. This makes stakeholder management even more critical to success. Teams with high expectations for a project may need to have those expectations moderated. Teams with low expectations for a project cannot be allowed to use that as an excuse for missing delivery dates. Again, having well established relationships with stakeholders can minimize any tendency to provide less project support in this situation.

CHALLENGE 4: THE OVERALL TECHNICAL SOLUTION IS SUPPORTED BY MULTIPLE TEAMS, EACH WITH ITS OWN LIST OF PRIORITIES

4

• Even the simplest, most routine of changes can require extensive coordination. At one client, we encountered a scenario where applying a patch to an Oracle database required coordinating with, among others, teams from the SOA Application Management group, Unix Operations, Database Operations, and the LAN team, in addition to the Change Control Board.

When even simple tasks require coordination among multiple teams, the risk to the schedule multiplies.

A mitigation strategy that creates and builds professional relationships to address risks, constraints, and prioritization of work is vital to the project’s success.

• Facilitate communications: When tasks must be coordinated across multiple teams, never assume those teams are talking to each other. The PM must adopt the role of facilitator to make sure that Team A and Team B really have discussed an issue in the timeframe required by the schedule. In this effort, be persistent but never pester. Being the intermediary provides a great opportunity to gain intelligence about the client and competitors. Providing that intelligence (appropriately) to all the teams in question increases your value to them, as well.

• Official scope is a floor not a ceiling, so help elsewhere if possible:This does not mean to embrace scope creep. It means understanding your client’s requirements and the range of skills the delivery team can offer. If the client has a need that does not impede the team’s ability to deliver, offer to help. This helps strengthen relationships and builds a positive brand for a delivery team with the client. A Statement of Work should be viewed as the floor from which to start, not a ceiling above which it is impossible to rise.

• Report dependencies early and often, but never point fingers: This is the “leading the horse to water and hope he drinks” approach to project reporting. Regardless of the challenges imposed by the external groups, those relationships cannot be compromised by unprofessional reporting. If there is a dependency, report it while taking care to use the least inflammatory language possible.

Done properly, the PM can motivate an executive to take the action needed to advance a project while preserving relationships with other organizations.

© Sapient Corporation 2012

• Know the process calendar: Organizations typically have a change management process that enforces a minimum timeline to submit, review, and approve requested changes. Understanding that calendar is a key to building your schedule. Ten change requests with a minimum of three days required for the entire process can add six calendar weeks to a timeline. Not knowing the process calendar can result in shortchanged task durations and create a schedule risk where none exists. Understanding the calendar is also critical to maintaining relationships with those upon whom the project depends. A PM should strive to avoid asking someone to complete a process at the last possible minute. But if this happens, the relationships that have been cultivated can be a saving grace.

• When faced with technical problems, be bulletproof on process compliance: While a well-documented failure is not a good defense, it is better than no defense.

Sometimes things simply don’t go according to plan. It is not realistic to expect every activity will be completed without problems. This defensive mitigation strategy combats the risk that failure to follow the process will cast doubt on the delivery team’s competence.

• Documenting lessons learned: When, not if, something goes wrong, documenting lessons learned is extremely important. Not only will it minimize the risk of encountering the same problem again, but it demonstrates a proactive problem-solving approach to the client.

CHALLENGE 5: LACK OF CONTROL OF THE DEVELOPMENT ENVIRONMENT In a typical non-production environment, a development team has substantial freedom to work. However, if this is not the case, risks escalate. At one client organization, changes to the non-production environments required approval from several external organizations, including coordination with a client application that required retesting after each change. Because the processes around non-production environments were substantially looser than those around production systems, formal avenues to move the project forward were limited. In this case, the key mitigation strategy is focused on creating and maintaining relationships.

© Sapient Corporation 2012

• Informal processes make relationships supremely important: When there is no formal change control process, relationships become critical. Being able to visit someone with whom a relationship has been built will be far more effective than sending an email, or making a phone call, and hoping that person will eventually get to the work. Even if the response is unanticipated, a quick negative decision can be escalated or otherwise discussed among stakeholders to assess the impact.

The lack of a decision, and the time wasted in attempting to get one, is often worse than a negative decision that can be addressed.

CHALLENGE 6: FREQUENT CHANGES IN THE PROJECT’S PLAN DUE TO EXTERNAL DEPENDENCIES ARE ADDRESSED IN A WAY THAT IS INCONSISTENT WITH AN AGILE APPROACH If the client adopts an Agile approach, constant change is not only expected but embraced (but still needs to be managed). However if the client uses a waterfall model, and the most accurate statement that can be made about a schedule after it is updated is “This is wrong,” what can a PM to do to mitigate schedule risk? In our experience, numerous external dependencies on work activities create more opportunities for delay as schedules get pushed out to the lowest common denominator date available. In this situation, the PM has a number of mitigation options.

• Carefully estimate items the delivery team can control and document those that it cannot: If it becomes apparent the external dependencies facing the project represent substantial schedule risk, never assume timely completion of tasks outside the delivery team. Add as much lag time as possible to the schedule and explain why to the client. It is always wise to give clients the opportunity to accept the lag or push back on the delays. It is also imperative to be open and accurate when documenting dependencies. Clients like surprises even less than they like delays.

• Develop work packages in ways that allow the most flexibility: Program Managers tend to think that if C should be done after task B, then it must be done after task B. But there are often tasks, or portions of tasks, that can be done out of order. For example, when experiencing delays in building a non-production environment, but the delivery team remains confident

5

Program Management in Difficult Environments: How to turn risks and constraints into advantages

it will also build a production environment, start what activities that can be done in production even though non-prod is incomplete. While perhaps less than ideal, maintaining the dependency can result in a status report full of delays rather than progress. Starting preliminary portions of the next major activity can show progress, even if that progress is out of sequence. Mitigate schedule risk posed by dependencies by building as few of them into your schedule as possible.

• Reduce dependencies via process arbitrage: For example, A Trouble Ticket versus. a full Change Request: Organizations do not always have clear rules on what changes require review by a full Change Management process and what can be done by a less intensive Trouble Ticket/Break-Fix approach. Use a good relationship with the people who would actually do the work to ask them which approach is preferred and there is a good chance the less process-intensive one will be chosen.

• Be totally transparent on the reasons for delay and their impacts: This continues the theme of being open and honest, but not accusatory, in reporting. Managing the client’s expectations is key not only in making progress, but in protecting the reputation of the delivery team. The PM should never put himself at risk of appearing to hide relevant information from a client.

TURNING DISADVANTAGE INTO ADVANTAGE Even within the context of managing projects in environments fraught with issues outside the control of the delivery team, ample opportunities exist to turn these disadvantages into advantages. It is the PM’s responsibility to identify these opportunities. Listed below are some specific examples of disadvantages and how to change them into advantages.

DISADVANTAGE: INCONSISTENT EXECUTIVE COMMUNICATIONS When executive communications about priorities and policies are inconsistent in content and enforcement, and different working groups have different priorities, longterm planning becomes difficult. However, opportunities exist within such an environment that can yield positive returns.

6

For example, one project was experiencing delays in the official scope of work due to external dependencies.

Aside from the obvious impact to schedule, the team was underutilized, and morale was suffering. In a routine status briefing, an executive made an off-hand comment regarding a new technology the client that was considering as part of their long-term architecture. The executive’s comment prompted the project manager to have his team build a proof of concept version of the deliverable based on the new technology. This demonstrated to the customer that not only were we carefully listening to the executive, but also that the team did not need to be told to advance our client’s interests. The team moved forward in a proactive manner. That this occurred during a stagnant period of our official work helped fill in the gap and allowed engineers to acquire new skills without impact to the schedule. Sapient demonstrated the team was dedicated to more than generating revenue, and had the interests of the enterprise at heart.

In another example, Sapient took over an existing project, the success of which was directly tied to the client’s executive bonus payout. The functional requirements for this effort were poorly defined, leaving a gray area against which to measure success. In spite of the fact that this project was significantly behind schedule when we took over, we were able to identify a definition for success that met the letter of the requirements and allowed us to demonstrate success to the executive. Instead of simply accepting the gap and viewing it only as a constraint, we realized it was also an opportunity to tie the project work directly to the executive’s personal objectives. This created a very clear message of our focus on client driven success, and generated a strong positive brand for Sapient.

DISADVANTAGE: STOVEPIPED ORGANIZATIONS When different parts of an organization do not communicate effectively, we believe it is the delivery team’s role to take up the slack. One example from our experience involved two client organizations, both with some responsibility for naming standards, and unable to agree on the naming convention for a data center. The issue was outside our tasking to resolve, but our success depended on a prompt resolution to the issue. Instead of simply reporting the dependency and hoping “the horse would drink”, we initiated open communications between

© Sapient Corporation 2012

the parties, involved impacted stakeholders, scheduled meetings, pushed for a resolution that satisfied all parties, and documented the outcome.

A second example focused on technically integrating network technologies from different vendors that were not integrated in this client environment. Our project required that a solution be found, but the “official” responsibility for finding it did not lie within the project team. This was another external dependency that might have delayed the project. Even though this work was clearly not within our Statement of Work, we prototyped and recommended a solution, tested it in a development environment, implemented it as a local solution for our project, and eventually saw it rolled out as an enterprise standard.

Both situations provided two key advantages for Sapient.

First, we were able to gain intelligence on our competitors by being the intermediary in the flow of information. We became privy to information we would not have seen had we simply hidden behind our official scope. It also enabled us to see who did and did not step up to the plate in the face of out of the box challenges. Second, we fostered a reputation for the delivery team as being less focused on driving revenue and more focused on driving toward solutions and delivering added value whenever opportunities presented themselves.

DISADVANTAGE: EXTERNAL RESOURCES OF VARYING SKILL LEVELS Tasks outside the delivery team’s control are often dependent on professionals with varying skill and experience levels. When we encounter this situation, we continue to strive for excellence and provide quality deliverables. We take proactive steps to advance the skill level of these support teams whenever possible.

At one client, the project included network and security configurations that were unfamiliar to the in-house teams that would be ultimately tasked with supporting the infrastructure we were developing. Anticipating this need, we took steps to include the teams in the design phase of the project. In addition, we worked one-on-one with the members of these teams to develop their skills to meet the required level. This turned the disadvantage of an inadequately skilled client organization into the advantage of a team that had the required skills to make

© Sapient Corporation 2012

us successful. Their newfound skills and knowledge continued to provide value to the client long after our project was completed. Again, Sapient was recognized as a company that focuses on the client’s best interests, not simply revenue.

SUMMARY The four important behaviors that every PM should remember are: • Maintain a strategic focus on what the client needs, but constantly reevaluate tactics • Fill gaps in process with relationships, not more process • People are your allies. Process is your defense • Opportunities to advance your reputation, if not your project, are always available Time and time again we show the importance of building and maintaining professional relationships and fostering effective communications in order to mitigate the risks and constraints. Yet there is something more fundamental at work – Attitude. If a PM comes to work everyday focusing on risks and constraints, that PM is likely to see only risks and be constrained. If the PM comes to work focused on critical thinking, problem solving, and success, then that PM is likely to think critically, solve some problems, and be viewed by the client and the delivery team as a success.

This, more than any other factor, is the key mitigation strategy that turns risks and constraints into advantage.

7

Program Management in Difficult Environments: How to turn risks and constraints into advantages

ABOUT THE AUTHORS

Jeff Toppall’s career spans 15 years of program and technical management for public and private clients on projects ranging from consumer and back office software development to infrastructure delivery for both national and international markets. He holds an M.A. in Telecommunications from George Washington University and a B.A. in Broadcast Journalism and History from Syracuse University.

Jeff Toppall, PMP

Bob Meyer has been in the IS / IT field for more than 30 years, initially as a developer and for the last 20 years in project and program management for government and commercial clients. He has consulted for national security and financial regulatory agencies, DOD, and the telecommunications industry. Bob holds a BA in Economics from Allegheny College.

Bob Meyer, PMP

8

Š Sapient Corporation 2012

Š Sapient Corporation 2012

9