Skip to main content

Tag: Stakeholder

GEM: The Most Crucial Factors for Project Success

Written by Chi-Pong Wong on . Posted in Articles. 12 Comments on GEM: The Most Crucial Factors for Project Success

Three crucial factors for project success

Successful projects are built upon many factors. Among them, three are most crucial. They are like the pillars of a solid foundation upon which building successful projects becomes possible. Missing these three vital factors, project success would be any project manager’s pie in the sky.

GEM is the foundation built by the three most vital success factors

Having all success factors working in harmony for any project is not practical, if not impossible, and project managers typically have to cope with what they don’t have when striving for successes. To conquer project perils like technical illiteracy, unsuspected risks, scope creeps, ineffective tools, contentious stakeholder collaborations, over budget, under resource or bloated schedules, project managers must have three most crucial success factors on their side. Missing any one of these three will very likely cause the projects to fail. These three vital factors are the pillars to hold up the foundations upon which building successful projects becomes possible. This foundation is named GEM, which is the acronym of the first letters of the three pillars, which are:

  • Global corporate culture of the company: Global corporate culture is a corporate culture when all units and pieces of the corporation embrace the same set of values, and their employees’ behaviors manifest their alignment and support of these values. Global corporate cultures embracing proper project management methodology is the first most essential success factor that every project manager needs. Missing this factor, project managers will have to fight uphill battles on almost anything needed to steer and manage the projects to stay on their right courses. When a business does not possess a good and disciplined project management culture, team members could feel that project management tasks hinder rather than facilitate their work, and would not be fully cooperative with the project managers. In the absence of this culture, there will not be standard processes that everyone adheres to, and sound methods and proven practices in the project management profession will not be leveraged to handle scope creeps, risk management, resource rebalancing, or any other tasks or issues. Project success without a global corporate culture favoring proper project management procedures, if at all possible, would be by chance, not by design, hard work, or sound project management operations.
  • Empowerment of the project manager: Empowerment is the second-most essential success factor that every project manager needs. Project managers absolutely need to be empowered to handle not only the routine project management activities effectively, but also the menaces like scope creeps, uncooperative and noncommittal stakeholders, over budget, under resource, inflated schedule, etc. Project managers have to be truly empowered to lead and to appropriate actions on scope, schedule, budget and resource matters. Project managers define RACI charts to clarify stakeholder ownerships of project tasks. They need to be empowered to hold the stakeholders committed to their tasks. Underpowered project managers could not reject scope changes during midstream, or adjust budgets, schedules and resources to realign with the changed project scopes. Inabilities caused by under-empowerment impair the project managers’ prospects to lead the projects to success.
  • Management sponsorship, especially executive sponsorship: Management sponsorship is the third-most essential success factor that every project manager needs. This vital factor is needed to foster and strengthen a global corporate project management culture and to make empowerment of the project managers a natural and sustainable delegation. Management, particularly executives, must believe in and commit to proper project management by walking the talks. Without management sponsorship, the empowerment given to the project managers are conditional, restrictive and temporary at best. Without management sponsorship, businesses’ global project management cultures will crumble. Without management sponsorship, project managers will be continually fighting project perils rather than leading project successes.

Management sponsorship is GEM’s most vital pillar

The three pillars of GEM form the foundation of project successes, and the third pillar is the most vital of them all. Weak global corporate culture in favor of proper project management can be nurtured and strengthened, and underpowered project managers can be further empowered as long as the management of a corporation is fully committed to sponsor the projects. On the other hand, projects lacking management sponsorship could perish because global corporate culture favoring proper project management could crumble, power of the project managers could be tapered off, and project menaces could creep in to trigger project hazards when there is not a solid GEM foundation to base on.

Imagine a young corporation formed by co-founders who embrace proper project management methodology. At the beginning, not all employees endorse this project management value, but the top executives’ sponsorship leads to immediate empowerment of the project managers. Additionally, these top executives make embracing proper project management procedures a corporate mission. These two motions send a strong message to the entire corporation that disciplined project management practice is needed for project success and that everyone must endorse this value. Given time, employees who refuse to assimilate to this culture will be forced out voluntarily or involuntarily, the corporate project management culture will be nurtured to bloom and project managers will be truly empowered to lead.

Conclusion

There are many factors for project success. Among them global corporate culture that favors project management methodology, empowered project managers who could lead effectively and management sponsorship that stands behind the project managers form the three pillars of the GEM foundation upon which other success factors act as building blocks to create project successes. Furthermore, among the three pillars of the GEM foundation, management sponsorship is the most pivotal without which the other two pillars could disintegrate and project success will remain a pipe dream. Therefore, when the GEM foundation is not strong, building management sponsorship above all else is the best and most essential starting point to strengthen the GEM foundation for project successes. 

Don’t forget to leave your comments below.

From the Sponsor’s Desk – Fifteen Must-Haves for High Performance Teams

Written by Drew Davison on . Posted in Articles. 12 Comments on From the Sponsor’s Desk – Fifteen Must-Haves for High Performance Teams

FEATURE Apr10thIn my last post, we looked at the steps taken by an HVAC contractor to develop and deliver an innovative offering to its clients and the challenges it faced dealing with a number of unknowns and uncertainties. Unfortunately, it failed to identify and engage key stakeholders and manage the project risks and paid the price, in dollars and credibility.

In this post, we’ll look at how one IT organization responded to corporate pressure to deliver more, faster and at less cost by transforming its organization using high performance team principles.

Thanks to reader K.B. for providing the details on this case.

The Situation

In this large financial services company, the beginning of the teamwork in­itiative was the recognition by the IT organization that de­mand for its support was growing. Systems and services were on the critical path for al­most every business initiative, and the ability to deliver was not improving fast enough to meet the demand.

The CIO had a vision: to transform IT on the model of a professional service firm and thus enhance its contribution to the plans, knowledge and results of the business units served. Her plan included a number of changes to support this vision based on three key principles:

  • Professional staff would actively manage their own skill and career growth.
  • Managers would focus on skill de­velopment needs and assist the pro­fessional staff with their skill and career development.
  • Work would be handled by teams, which would form and operate on the basis of self-managed team principles.

Information Technology had a reason­ably good track record and 600 staff, mostly long-service employees. Most were already involved in teams to deliver computing services or develop application systems, but most of these teams operated in a hierarchical fashion, with team members deferring to man­agers for direction and decisions. The challenge was to transform the oper­ating style of this organization.

The Goal

The CIO and senior IT managers established a performance improve­ment target of 30 per cent over 18 months in the twenty teams they designated as priority. Other teams would be supported as the need dictated and the capacity allowed.

The Project

To get the change off to a good start, IT formed a small team, known as the SMT (Self-Managed Team) for lack of a better label. Four of the five team members had from 1 to 23 years of IT experience. The fifth was a for­mer IT staff member working in the Human Resources organization. All worked on the assignment on a part-time basis.

The SMT relied on an external con­sultant to help understand the issues and opportuni­ties and to give added impetus to the rollout of team principles and practices. The consultant assisted the team with exploratory and planning sessions and two full-day orientation sessions for all IT management and inter­ested business partners.

Two key findings emerged during the orientation and introduction stages:

  • Most people didn’t really recognize or acknowledge the fundamental dif­ferences between the operation of existing teams and the desired oper­ating style of a self-managed team, although participants would nod knowingly if the topic was raised. The ideas be­hind self-managed teams are not new but they are attractive. Teams and managers were sometimes reluctant to admit that these desirable team at­tributes were not in place. Conse­quently, the SMT would hear comments like ‘we’re already self-managed” or “we already do all those things.” Not only did this not foster the desired re­sults, the SMT would have to work very hard to undo these beliefs.
  • Self-managed teams didn’t just magi­cally emerge out of existing teams because someone said it was a good idea. In fact, because of the perspectives described above, many managers and teams concluded that they didn’t have to change anything. For those who did realize there was a differ­ence, the path to self-management was not clear. With all the other de­mands on managers and teams, it was easy to put off figuring out how to make it happen.

The SMT addressed these concerns by de­veloping and producing a 30-page booklet presenting the Information Technology version of self-managed teams. The team borrowed ideas from a variety of sources to ensure the material was relevant to IT circumstances and cov­ered the following topics:

  • what is a self-managed team?
  • what is a self-managed team . . . not?
  • why do we need self-managed teams?
  • requirements for successful self-man­aged teams
  • team principles
  • phases of team development
  • team boundaries
  • roles and responsibilities
  • skills and training
  • an individual self-check test
  • where and how to get help

With the booklet in hand, the SMT proceeded to arrange and conduct a two-hour introduction to self-managed teams for all Information Technology and involved business staff. The introduction was based on the booklet (distributed in advance) and structured to provide opportuni­ties for questions and discussion. It was also used to advertise the availability of SMT members to assist with the implementation of self-managed team principles and practices. The sessions were conducted on a team-by-team basis, with the team leader/manager in attendance.

Perhaps the most significant benefit from developing the booklet and con­ducting the introductory sessions was the understanding and insight the SMT members developed about how to’ make the team concepts work. As a result of the introductory ses­sions, members of the SMT began to notice an increase in interest and in re­quests for information and assistance. But the misconceptions didn’t disappear:

“We’re self-managed! We don’t need a manager to tell us what to do!” – a team member

“They’re self-managed! It’s not my job to tell them what to do!” – a team manager

“We say we are self-managed, therefore we are.” – a skeptic

“We’ve always been self-managed.” – an optimist

In addition, while the SMT “thought” things were beginning to happen, they had no measures to es­tablish conclusively how they were doing. It was time to practice what they had been preached to others: clarify the mandate with the stakeholders and establish measures to track performance and progress.

In follow-up meetings with the stakeholders, a number of things were revealed:

  • The term “high-performance team” was preferred over the term “self-managed team” because it was less open to misinterpretation, provided greater latitude for solutions and placed the emphasis on result rather than method.
  • The SMT members agreed among themselves to deliver a 30 per cent performance improvement in the targeted teams as well as the ones they chose to assist.

The SMT developed a team assessment tool based on a variety of sources using the percentage change from the first team assessment over the 18 month period as their measurement framework. The team assessment tool addressed team member perceptions on a scale of 1 to 9 on 15 critical success factors for high-performance teams:

  1. Clarity of team mission, vision, goals and priorities
  2. Member and stakeholder acceptance of team mission, vision, goals, priorities
  3. Clarity of specific measures to track performance against goals
  4. Amount of challenge in team’s task
  5. Team’s value to members as a place to acquire new skills
  6. Support for team from sponsors
  7. Skill resources in team (including leadership)
  8. Team’s size
  9. Facilities, technology and support
  10. Team’s reporting relationship with sponsor
  11. Ground rules on team operation, confidentiality, sign-off, etc.
  12. Team roles, boundaries and auth­ority limits
  13. Communication between this and other relevant individuals, groups
  14. Team’s measured performance against established goals
  15. Sponsor satisfaction

The team assessment was completed in a one-hour review with all team mem­bers and was facilitated by a member of the SMT. Priorities and action items for the team to address were agreed upon in the review. Subsequent reviews were performed by the team members them­selves or with the help of a facilitator.

The Results

The assessments were completed on 25 teams over 18 months, fifteen development teams and ten operational groups. The average re­sult for the initial assessments was 5.2 based on a scale of 1 to 9 where 9 is high performance and 1 indicates a definite need for improvement. Team results ranged from a high of 7.44 to a low of 3.40.

Questions 4 and 5 received the highest initial responses, averaging 7.0 and 7.1, respectively. The lowest responses were reserved for questions 14 and 15, with results of 3.7 and 4.0, respectively.

After eighteen months, assess­ments revealed an average im­provement of slightly over 37 per cent, nicely above the 30 per cent target. Perhaps what was most important was the awareness teams developed when they had been through an assessment two or three times. Team members under­stood the meaning and significance of the 15 success factors, and team dia­logue appeared more open, more honest and more focused on results.

It was also discovered that team performance improvement was seldom linear. Average scores by teams over the eighteen months looked like a chart for the Dow Jones stock index, reaching ever upward and then dropping like a stone in response to some internal or external trauma. Things like the addition or departure of IT or business staff, organization changes that impacted a team’s stakeholders and technology and business process changes accounted for most of the drops. Teams that had internalized the high performance team practices and tools did a much better job of responding to the assessment drop and bringing their scores back up.

It was also discovered that some teams just don’t do very well. Most teams in that category didn’t have the right mix of attitudes and personalities and the collective commitment to learn and grow. Removing problem staff, often initiated by the other team members, and in depth coaching and facilitation usually turned the situation around.

Is the team assessment tool the de­finitive method for measuring team per­formance? Absolutely not! The SMT’s ultimate goal was to be able to track the im­provements in team performance on the basis of each team’s own measure as ex­pressed in questions 14 and 15. However, even when teams have clear goals and measures, the team assessment tool is a useful catalyst to focus attention on the means of achieving those goals.

Finally, business stakeholders felt IT’s quality, responsiveness and cost-effectiveness had improved noticeably in the twenty-five teams targeted. It was a ringing endorsement for the program.

How a Great Team Achieved Success

The SMT did a number of things right.

  • They lined up and leveraged the key stakeholders in IT and the business as they went.
  • They brought in some external expertise right up front to address their own knowledge and skill gaps.
  • They learned as they progressed and adapted their approaches accordingly.
  • They built up the organization’s store of best practices around high performance teams, something that was leveraged productively by other departments within the organization that had heard of IT’s success.
  • They managed to internalize the high performance principles and practices, even with part time commitment. They walked the talk.
  • They used Project Pre-check’s three building blocks to perfection – engaged stakeholders, a defined process and a best practice based decision framework.

What did they learn from this ad­venture?

  • Active and sustained sponsorship is essential. Without the vision and commitment of the CIO and visible support of IT and business management throughout the organization, mo­mentum and interest would have dis­sipated quickly.
  • Establish goals and measures up front. This is good advice for any team and absolutely essential for a team charged with implementing self-man­aged principles and practices.
  • Communicate! Communicate! Com­municate! Celebrate victories. Ack­nowledge mistakes. Share learnings. Stay on the front page.

If you find yourself in a similar situation, remember to consider Project Pre-Check’s three building blocks right up front and put these points on your checklist of things to do so you and your team mates can be a Great Team too.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll present it for others to learn from and comment on. Thanks.

Don’t forget to leave your comments below.

From the Sponsor’s Desk – Tackle Your Project’s Highest Risks First

Written by Drew Davison on . Posted in Articles. 16 Comments on From the Sponsor’s Desk – Tackle Your Project’s Highest Risks First

Davison FeatureArticle March27In my last post, we looked at how one program manager delivered a major change successfully in spite of the fact the sponsor was not interested and not involved in helping the organization manage a significant corporate initiative. His secret weapon: coercion!

In this post, we’ll look at the steps taken by an HVAC contractor to develop and deliver an innovative offering to its clients and the challenges it faced dealing with a number of unknowns and uncertainties. Unfortunately, it failed to identify and manage the project risks and paid the price, in dollars and credibility.

Thanks to reader M.P. for providing the details on this case.

The Situation

This heating, ventilation and air conditioning (HVAC) contractor delivered custom solutions to commercial and industrial businesses. The contractor had been in business for over 25 years but had experienced a slowdown in work because of the 2008 financial crisis and the resulting economic downturn. The three partners were looking for other opportunities to grow revenues and differentiate themselves in a very competitive market. 

In response to these challenges, they conceived of and designed a configurable, off-the-shelf HVAC solution that could be adapted and tailored to a wide variety of needs to provide the required heating, ventilation, air conditioning, noise abatement and odor control services and meet specific pre-established operating targets. Their target market was in the 1000 square foot to 20,000 square foot range. The advantages for their clients included lower costs, faster installation, known and assured operating costs and demonstrated performance. The anticipated benefits for the company included increased revenue, lower costs and higher profit margins. In addition, because their solution required a long term maintenance agreement to keep the systems running at target specifications, the company would have a more stable revenue stream over the long term. 

The partners had built a prototype to prove the concept and were able to sell one of their existing clients on the new system. The client was opening a new high end restaurant in a largely residential area and was counting on the locals for much of his business. He wanted to provide a quiet and comfortable dining experience while making sure that the noise and smells coming from his eatery didn’t earn the animosity of his neighbours and drive prospective diners away. 

The Goal

The client’s planned opening date for the new restaurant was in nine months. In that time the contractor needed to design, build and install the mechanical systems for the new site. That included the duct work as well as the configuration and placement of fans, sensors and filters. The biggest challenges were the software components: one piece would be used to create the design specifications for the site, the other would monitor and adjust the performance of the system on a real time basis to stay within the agreed upon specs. Initial versions had been developed for use in the prototype but they were crude applications in need of considerable refinement. 

The contractor planned to spend $400,000 on the first implementation including $350,000 for the software development and testing effort. The partners projected that with three more similar sized clients on the books they could start showing a profit on the venture.

Their first client had agreed to pay $100,000 for the system plus $15,000 annually for five years to cover ongoing monitoring and maintenance. The contract with the client included performance penalties of $5,000 per month for late delivery. 

The Project

The partners proceeded to hire a contract project manager to guide the software development effort. The actual design and coding was to be done by a local software development firm with target completion in six months. That would allow three months for the actual physical installation and final testing. The partners planned on using in-house engineering, electrical, sheet metal and welding staff for the remainder of the work. The client insisted that his electricians and plumbers do the actual hook-up on site.

The new project manager proceeded to work with the software development team to refine the specifications for both applications based on the prototype and feedback from the partners and engineering staff. Both applications were re-architected to allow input of the variables rather than embedding the information in code as was done in the prototype. A highly configurable physical model was built with the co-operation of the engineering staff to support ongoing application testing and prove the accuracy of the software’s configurations.

The prototype software had made several key assumptions about the characteristics and performance parameters of the various components including motors, compressors, heaters, fans, filters, sensors, insulation and ductwork. As the testing of the configuration software progressed, it became clear that those assumptions would not deliver the kind of performance needed to satisfy all possible situations. The partners authorized the PM to engage with the component manufacturers and suppliers to identify additional options and associated performance parameters and to include those in the model. 

Of course, bringing in new players takes time and adds complexity and cost, especially in the later stages of a project. In this case, it quadrupled the component inventory and significantly extended the testing time, moving target completion of the software out another three months. Recognizing that the software delay would push off implementation and result in monthly performance penalties, the partners authorized the engineering staff to start installing the HVAC system using an early configuration model.

The Results 

The restaurant opened three months later than planned, an embarrassment to the contractor and the client. The delay was due almost entirely to repeated changes in the HVAC system to meet target specs. The project was $90,000 over budget, $60,000 of that on the software side. The contractor was able to negotiate the performance penalties down, arguing that the client’s trades people were as much of a factor in the delay.

Ultimately, the configuration and monitoring applications were completed. Unfortunately, the configuration tool was never able to generate wholly acceptable specifications without a great deal of manual intervention and the contractor stopped development. The monitoring application was used with the initial client and continues in use today, providing value to clients and additional revenue for the contractor.

How a Great Project Manager Would Have Helped

This was an unfortunate case of enthusiasm for the idea over-riding some fundamental change management and project management principles. The three partners and the PM started out with a blank slate. As a result, they ignored or overlooked some critical decisions that could have changed the project outcome for the better. By focusing the PM on just the software development effort, the three partners lost overall control of the undertaking. 

There was no risk plan in place that attacked the most significant risks right up front. As so often happens, the biggest risks were left to the last where they could do the most damage. There was no thought given to phasing and staging the delivery in manageable, bite-sized pieces. The PM focused exclusively on the software development effort until he belatedly realized he’d also have to engage others outside his team to be successful.

A great PM would have pushed back and insisted that someone be charged with responsibility for the whole project and ensuring all the pieces fit as needed. A great PM would have used any one of a number of standard industry frameworks or their own personal practices to ensure the bases were covered. 

For example, use of Project Pre-Check’s stakeholder model would have helped identify the change agent role gap. It would have also helped identify the component manufacturers and vendors as vital stakeholders early on. Use of the Project Pre-Check Decision Framework would have helped the stakeholders identify relevant Decision Areas that needed to be addressed including extended and new external relationships with the manufacturers and vendors, phasing and staging opportunities and prototyping and piloting options to accelerate delivery and reduce risk. It would have also highlighted the need for a comprehensive risk plan to guide the project through and around the many challenges and a resource plan that addressed the skills needed from the contractor’s staff, the client’s trades personnel, the software developer and the component manufactures and vendors. It could have been a very different and highly successful undertaking! If only!

If you find yourself in a similar situation, remember to consider Project Pre-Check’s three blocks right up front and put these points on your checklist of things to do so you too can be a Great Project Manager.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll present it for others to learn from and comment on. Thanks

Don’t forget to leave your comments below.

From the Sponsor’s Desk – Using Coercion for Program Success

Written by Drew Davison on . Posted in Articles. 11 Comments on From the Sponsor’s Desk – Using Coercion for Program Success

In my last post, we looked at how a director’s refusal to engage the project sponsor on a multi-million dollar reorganization resulted in project failure and his own loss of position. We also looked at the actions project managers can take to identify and engage the right stakeholders in the right roles to improve the performance of their projects.

In this post, we’ll look at how one program manager delivered a major change successfully in spite of the fact the sponsor was not interested and not involved in helping the organization manage a significant corporate initiative. His secret weapon: coercion!

Thanks to reader B.F. for contributing the details on this case.

The Situation

This global financial services organization identified a new product opportunity that would generate substantial new revenues and provide a significant competitive advantage over competing firms in all its markets. However, because the product could be duplicated by its competitors once they recognized the opportunity, there was considerable pressure to deliver quickly and quietly.

The Goal

The organization proceeded to launch a program to deliver the new product to all its global markets. The target budget for the total effort was $10 million and three years for full operation. The first implementation of the multi-phased effort was forecast at $7 million with a delivery target of 30 months. 

The Project

The program was a top corporate priority and was recognized as such throughout the company. Because of its global impact, funding was provided by each operating unit in accordance with anticipated revenue generation. North America was expected to be the biggest beneficiary and so was the largest contributor, followed by the UK, Europe, Asia, South America and Australia/New Zealand.

The CEO of the North American unit was designated as sponsor and the South American organization was targeted as the first market to receive the new product. A contract program director was selected, reporting to the North American CIO. His team was based in New York and was accountable for planning and guiding business process design, software development and testing using a purchased application and significant vendor resources, acquisition and installation of new technology and the implementation of the whole package, adapted to meet the unique needs of each market.

The program director managed 20 different teams around the world with over 120 direct participants and many more staff involved behind the scenes. He attempted to schedule regular meetings with the sponsor, the North American CEO, to ensure his thoughts and expectations were understood and satisfied but he was rebuffed. The program director was told that the CEO would only be involved on an exception basis. He was to report through the North American CIO and ensure that the fourteen other unit executives around the globe were kept informed.

The program director was a seasoned manager with lots of relevant experiences and insights. He knew the sponsorship arrangement was a significant risk. He also saw the global nature of the effort as major risk. So he implemented the following practices to counter these risks:

  • He established a sizeable travel budget to cover frequent visits by him and key team members to each affected business unit and for the key business unit staff to visit the facilities in New York. He hoped that the face time with the team members and key stakeholders would facilitate communication, accelerate decision making and ensure the needs of each region were well understood and reflected in the final product.
  • He built his plans iteratively, putting a high level framework in place that focused on milestones, letting each region build the details within the overall framework and dealing with each unit as issues and conflicts arose. Think globally, act locally.
  • Once the plans were finalized, he adopted a mantra of “no slippage”, recognizing that failure of any one element to deliver on plan and budget would have massive ripple effects across the entire program. He repeated this message with all teams, with all stakeholders, in all offsite meetings, in all program meetings.
  • He established weekly conference calls to review the progress of each of the 20 teams against plan. Attendance was mandatory but teams could drop off after their report was presented and vetted.
  • Finally, the program director used coercion in place of an engaged sponsor. The program was seen as a career opportunity by a number of local VP’s and directors. They attempted to make their marks by challenging decisions, by criticizing program direction and progress and demanding additional capability. However, the program director felt he had enough senior management representation and backing around the world to ensure the project was addressing enterprise needs. So when he was challenged by a rogue director, he stressed that the sponsor was fully on side with the direction and progress and used the threat of the sponsor’s wrath and potential reprisal to thwart the attack. Fortunately, no one had the courage to push their points further. Coercion was a most effective .strategy!

The Results 

The program was delivered on time with a 20% budget overrun, which was due largely to incremental support for localization needs. The first implementation in the South American market disclosed a number of product design, process and software issues which were quickly remedied. The phase-in strategy helped subsequent releases to proceed flawlessly.

All those involved in and affected by the program where unanimously enthusiastic. Ironically, the uninterested and uninvolved sponsor received, and accepted, accolades for his “insightful vision and superb leadership”. Remember my first post at Project Times in May, 2010? A Great Project Manager – the Sponsor’s Best Friend! How true.

How a Great Program Manager Helped

We know that the ability of programs and projects to deliver the expected functionality with appropriate levels of quality, on budget and on schedule and achieve the anticipated benefits declines as the size of the initiatives increase. 

In this case the program director did a number of things right to address the size and virtual team challenges and achieve a successful result:

  • He focused in on the key stakeholders and their roles shortly after getting the job. That helped him understand the dynamics of the program and the personalities of the players.
  • He identified the key risks and developed mitigation plans to circumvent the challenges.
  • For the absentee sponsor risk, he built a coalition of support among the other stakeholders and actively managed those relationships and that support throughout the project.
  • He also used coercion and the threat of sponsor displeasure to ward off wayward executives.
  • For the risk posed by the involvement of 20 teams around the globe and including technology and software vendors, he traveled, his team traveled, the business leaders traveled, all to facilitate face to face dialogue. That helped build understanding, collegiality and a shared understanding and commitment to the goals to be realized and the solution that would deliver to each unit’s unique needs.
  • His approach to building and managing the program plan was a masterpiece of conceptualization and salesmanship. He got the teams to buy into the overall approach and milestone plan by fully engaging them in its development. Once committed, the teams built their detail plans in support of the master plan.
  • His tracking and control approach of mandatory weekly conference calls and the “no slippage” mandate helped reinforce the collaborate culture that was nurtured by the frequent face-to-face engagement. It placed accountability to deliver to plan firmly on each team, helped raise cross team issues yet put resolution at the local level.

What else could the project director have done to improve the result? One of the building blocks in Project Pre-Check is the Decision Framework, a model with 125 best practice based decision areas that enables early discovery of program scope and impact. It facilitates stakeholder deliberations about the breadth and depth of the planned change leading to full agreement on project and program content, direction and conduct. Use of a Decision Framework may have helped identify those localization needs and address some of the product design, process and software issues earlier in the program’s life cycle, leading to improved quality, faster delivery and lower costs. He promises to use it on his next project.

The program director admitted that he was exhausted at the end of the three year project, largely from the amount of travel required. He took a well-deserved sabbatical after the program was wrapped up, financed by the air miles he accumulated during the project. A well deserved reward.

If you find yourself in a similar situation, remember to consider Project Pre-Check’s three building blocks right up front and put these points on your checklist of things to do so you too can be a Great Program Manager.

In the interim, if you have a project experience, either good or bad, past or present, that you’d like to have examined through the Project Pre-Check lens and published in this blog, send me the details and we’ll present it for others to learn from and comment on. Thanks 

Don’t forget to leave your comments below.

The Agile Project Manager – Why are Software Projects Different?

Written by Robert Galen on . Posted in Articles. 15 Comments on The Agile Project Manager – Why are Software Projects Different?

Galen FeatureARTICLE Feb20I was doing some introductory agile training recently. As quite often happens, I got challenged about adopting agile in the “real world”. The implication I guess is that I’m from some other planet. So someone asked: how is agile is going to solve the following problem?

It seemed as if they had a project that had been going on for a while. It involved some new technologies that they hadn’t integrated before. I believe in this case, it was a Microsoft product that needed to be integrated with one of their major legacy products.

In traditional Waterfall fashion, they pulled together a project plan, did some requirements analysis and design, and approved the project through their phase-gate processes as a Phase 2 approved project.

From their leadership’s point of view, the rest was simply technical execution. The business was expecting the project to meet its scope and date commitments from the phase review. Life was good!

That was until…

The team found that physical integration with the Microsoft product was much more difficult than everyone had thought. The documentation was wrong and, in many cases, insufficient to describe how to effectively integrate. Calls to Microsoft went unanswered or didn’t really help with the challenges. The teams kept spinning their wheels; trying to sort out problem after problem and never seeming to make much forward progress.

When they went to their management team to report the challenge the project was encountering, they received two basic replies:

  • First, what is the team doing to hold the date? Did everyone realize that the date was incredibly important and that, heads would roll, if it slipped.
  • And second, when would they have answers to all of these problems and a solution? On what date would things settle back to normal and resume on plan?

So, making a long story short, the students question was: In the above situation, how would agile enable the team to give the stakeholders a definitive answer as to when this technical problem would be solved?

Software Projects

I think I disappointed them, because I said: Agile was not a silver bullet that would provide a magical end date for the solution to their problems.

I further offered that they needed to “push back” on their management demands for specific resolution dates. Clearly they were encountering “unexpected turbulence” in their project. Clearly they were doing the best they could. Complex problems are often impossible to accurately predict. Instead, the effort becomes one of intelligently and systematically attacking the problem—triangulating towards a solution.

This is simply the nature of software development. It’s exacerbated because software is soft, amorphous, and intangible and we’ve ALLOWED our customers and stakeholders to push us around in these situations. And since software is well, soft, we struggle to defend ourselves.

What “Agile” would do…

Now I explained that an agile approach would certainly help them in analyzing, finding and integrating a solution. For example, the following would be typical ‘agile’ reactions to the problem and probably generally helpful steps towards a solution:

  • Take a whole-team approach; perhaps getting a small team in a room, totally focused on solving the problem.
  • Raising the lack of Microsoft support as an impediment to Sr. Leadership team—asking them for help.
  • Ideating a backlog of things to try or an overall strategy with the team. Prioritizing them into the best workflow to augment discovery, learning, and progress.
  • Having daily stand-ups to ascertain progress, discovery and to plan adjustments.
  • Perhaps time-boxing their efforts into 1-week (or very short ‘Sprints’) so that they could provide progress insights.
  • Retrospecting often on what they’ve learned and then leveraging that for future adjustments.

I’ve often used these techniques with problems of this sort in agile and non-agile projects. And they certainly help to drive progress through ambiguous and chaotic situations!

Home Projects

In fact, I also responded with the following counter story.

I asked if any of them ever watched two shows on HGTV. There is The Property Brothers and Love it Or List it. In both cases, the shows take on renovation projects for relatively older homes. Usually these are extensive renovations. 

The shows usually start with the homeowners (or prospective homeowners) providing the hosts a budget. It’s normally a range, with a max that cannot be crossed. In many cases the bank imposes these hard limits. Then the hosts dive into the renovations. 

I remember in one episode of Love it Or List it, that Hilary (the renovation expert) uncovered a basement wall that was in danger of failing. It was bulging and leaning into the basement, preventing them from covering it. The bigger problem was that it was the foundation—or a load bearing wall. 

She had planned on simply covering the wall with drywall as part of the basement makeover. Instead, they had to literally build another foundation wall the length of the basement to shore up the failing foundation wall. This was unexpected and costly. I seem to recall that it would take 30% of the planned budget, and it was literally a must have from a building code and safety perspective.

When she first went to the homeowners and shared the news; they were upset. Then they went into denial that they would have to lose some of the enhancements that they’d planned for their budget. Then they yelled at Hilary as if it were her fault. But eventually, the emotions settled down and they worked with her to accommodate the changes and still have their highest priority renovation changes made.

The Unexpected

Encountering unexpected work in home projects happens ALL THE TIME. It’s the nature of things. And it always impacts expectations around budget (cost), time (schedule), and the overall design (scope expectations).

What’s surprising though is how the home stakeholders eventually adjust to the unexpected in a constructive way. Quite often, as my initial story showed, software stakeholders aren’t as accommodating. Somehow, they always expect the budget to be maintained along with the timeline and the scope. They demand creativity and initiative and hard work; as if those things aren’t happening. They question the commitment of the team to the company or their professionalism. 

If compromises are made, they’re often under the banner that the team failed the stakeholders in some way—that they didn’t do their job.

Wrapping Up

Agile won’t help these situations. In fact, it will make them potentially worse. Agile doesn’t work well with unrealistic or demanding customers. Or with customers who can’t handle the unexpected; who can’t handle the truth.

It expects customers to embrace unknown risks, discovered as early as possible, and then partner with the team towards trade-offs and solutions. It expects stakeholders to realize that software development is HARD and virtually impossible to guarantee. 

At the end of every Love it Or List it episode, both hosts have done a remarkable job and the clients are left with a very hard decision. Hilary always delivers a delightful renovation that is constrained to what she had to work with. She delivers the highest priority items, with high quality. She even throws a bit of a stretch in now and then. But the customers NEVER get 100% of their initial expectation. That’s because it was unrealistic.

From my perspective, software projects are no different than these home projects. Now if we can only get our software customers and stakeholders to have the maturity and realism of these homeowners. Well, I can hope can’t I?

Thanks for listening,
Bob.

Don’t forget to leave your comments below.