At crucial moments, well-timed executive decisions to steer projects and programmes are often in short supply. Subsequently, issues are left unresolved, key milestones are missed and the overall project delivery is delayed. Whilst it may appear that executive indecision is the main culprit behind the delay , it not the primary cause.
The root cause lies in how executive leadership is exercised in project steering committees. Normally, such committees are organized to encourage executives to provide guidance to project teams and participate in the resolution of issues amongst other responsibilities. However, this is usually done in a pluralistic manner as leadership is collectively shared amongst the executives. Figure 1.0 below shows a typical project hierarchy that consists of a project steering committee that has four C- level executives.
Figure 1.0 A typical Project Steering committee that exercises pluralistic leadership
In practice, this works fine for issues that are clear-cut to solve, as executive consensus is normally reached. But for more complex issues, executive agreement is at best painstakingly slow and more often than not, issues are deferred for the CEO’s input. The input can be either in the form of guidance consisting of principles, or a definitive decision thereby putting to rest any executive misgivings about solving the issue. Usually to obtain the CEO’s input requires the PMO together with the Project Sponsor to compete with other departments for a time slot with the CEO (predictably this can be an arduous wait, as CEOs are extremely busy people). The ensuing delay can very quickly bring the organization’s flagship project/programme to a complete halt, escalate costs, and squander opportunities to address competitors.
Another drawback of pluralistic leadership is that most solutions negotiated are often diluted to appease other executives. In the end, a compromise solution is reached, which neither addresses the problem, nor helps the project move forward. Its only achievement is that all the executives concur—not whether the solution is right, or wrong. Such resolutions render projects steering committees ineffective, deter Project Managers and Sponsors from escalating issues, and promotes a culture of indifference.
Yet, by making a small but significant change in the structure of the project steering committee, the aforementioned problems that plague traditional steering committees can be avoided. By the creation introduction of a ‘Project President’ in the steering committee, where the CxOs are demoted to subordinates, can engender an efficient mechanism to deal with issues quickly. Figure 1.1 below shows this new appointment of the Project President in relation to other executives.
Figure 1.1 The Project President and the Project Steering committee
To enable the Project President to discharge his/her responsibilities, the CEO must delegate all the powers related to project work. This implies that that the Project President must be able to overrule CxOs, interfere in their respective domains (within valid reason) and have a free rein to implement, or revoke decisions. As a consequence, the CxO’s are relieved of their collective leadership and the leadership is solely handed over to the Project President. In this new structure the CxO’s play an advisory role in decision making, whereby taking decisions is exclusively at the prerogative of the Project President. It also means that the Project President’s scope of work and stewardship encompasses all projects and programmes, and is not limited to one, or two initiatives i.e. the Project President may preside over several steering committees.
In the launch phase of the company, the CEO is the person entrusted with executing the role of the Project President. But soon after launch, the CEO usually hands over this responsibility to the CxOs collectively, without nominating a successor with all the powers of the CEO. Invariably, this pluralistic leadership exercised by the executives leads to the all too familiar problems mentioned earlier.
In practice, the best candidates amongst the CxO to perform the role of the Project President are the Chief commercial officer (CCO), Chief Operations Officer (COO) and the Chief Project Officer (CPO). However, the COO and CCO can become too pre-occupied with their day to day duties, and may not have enough time to execute the duties of the Project President. Therefore, the CPO is the natural candidate for this role, but in many organizations the CPO lacks the mandate and the support of fellow executives.
If company’s really want to improve their performance in the execution of initiatives and reduce time to market then they should take a serious look at restructuring project steering committees. By appointing the right person to play the role of the Project President, delivery of projects and programmes can be vastly improved.
Don't forget to leave your comments below.
Abid Mustafa is a seasoned professional with 18 years' experience in the IT and Telecommunications industry, specializing in enhancing corporate performance through the establishment and operation of executive PMOs and delivering tangible benefits through the management of complex transformation programs and projects. Currently, he is working as a director of corporate programs for a leading telecoms operator in the MENA region.
Have you ever attended a dining event where the host had a perfect understanding of his guests, knew just how to arrange the event and delivered a beautiful dining experience? Or, you may have attended several different kinds of special events at their invitation and they always seem to get it right.
The skills for setting the table for a dining event is not unlike the skills needed to deliver portfolio management to an organization. Three important skills will get you to the ideal portfolio management setting: 1) Your guests, their experiences and expectations; 2) the food and service costs; and 3) gathering guest taste feedback to make your next event even better.
Guests and their Experiences – Stakeholders and their Expectations
When you start to plan a dining event, you think about the guest list and consider palates and preferences. For instance, they may be frequent gourmet diners and have had broad exposure to different ethnic foods. There are also other considerations as you think about your potential guests: allergies, personalities, common interests, etc.
Similarly, when your organization starts to look at portfolio management as part of its service offering, you have numerous items to consider. You must understand your audience and stakeholders, and determine their level of understanding of portfolio management; it may be a common level of understanding or widely diverse. You also need to think about the company’s overall exposure to portfolio management, whether it’s rolled-up project reporting, idea intake or both. It’s also good to know if your company is a leader or follower, and what’s in it for them.
Back to your dinner plan. It’s time to think through the kind of menu you want to create and your end goal with the event. You may want to feed a large group in a short period of time, or create an intimate five-course fine-dining experience for a special occasion.
For your company’s efforts, you’ll determine what type of portfolio management to deliver and its overall purpose. You’ll work on the list of considerations, including the type of decisions your team supports – whether you’re a reporting team, audit team, if you’re helping align work to a company strategy, whether you support a chargeback system and more.
Understanding who is sitting at your table – whether it’s a dining table or a portfolio meeting table – will ensure a higher satisfaction rate when the experience is over and coffee is served. The team’s types of services and deliverables will depend on the functions your team will support. Knowing whether you serve the management team, the business team, the project teams, the resource managers or all of the above will determine the number and types of settings at your portfolio table.
Cost of Food and Labor – Portfolio Management Cost of Control
When planning a restaurant dining event, the chef needs to look at the cost of the meal as well as the cost of serving (or delivering) the meal. He considers the cost of ingredients versus the price for the meal, then determines the value and worth of the ingredients. For instance, serving fresh versus frozen can mean a lot to the quality of the overall meal.
Knowing which type of portfolio management your team will deliver, how much status reporting and what kinds of trending to collect for decision-making are just a few of the cost inputs to effectively run your team. You also need to consider the time it will take for idea intake, estimating at an idea level and balancing your portfolio forecasts. In addition, rolled-up status reporting and understanding how project change requests impact your current portfolios will impact your services.
Next is the type of table setting you’ll use. A buffet may work best if you’re serving large amounts of people and using a small serving staff. For a more formal affair, you may go all out with multiple forks and knives, cloth napkins, wine glasses, water glasses, a centerpiece, a chef, a sous chef, servers and bussers. You make sure you have the right venue, equipment and staff to execute the event and create the experience you desire for your guests. There is a cost of service associated with the type of menu you set, as well as your operational costs for space and equipment.
In addition, portfolio teams must account for the time needed to operate under organizational services or functions. These include, for example:
- Auditing or quality checks
- Phase gate reviews
- Collection of measure and metrics/reporting/trending
- Governance meetings
- Project health facilitation
- Portfolio idea management
- Portfolio change control – balancing portfolios
- Project staff augmentation or project rescues
- Center of excellence (process and tool ownership)
Portfolio teams also determine which resources are needed for the team (in terms of people, processes and tools). Depending on the functions or services, you may need "super PMs,” financial analysts or program managers. You then locate which tools and processes will best enable your team. The cost of running an organization is called the cost of control. The level of this cost of control may depend on the risk tolerance level of your organization. General industry standards, depending on the portfolio management service offering, can run between 15–25% of total project spending. 
“How was your Meal” or “Is this Working?”
There’s a wide set of expectations around the dining experience. Informal, fast-food or buffet diners may not hesitate to tell their hosts how they feel, and yet these diners know they have little impact on changing the long-term results. A fine-dining experience may not include a server that solicits feedback, but results can be gathered by what is left on the plate at the end of each course. Either way, both types of dining experiences want repeat customers.
Whether your portfolio team is in place to manage idea intake, project health escalations or quality checks, or to manage the financial aspects of your portfolio, continuous feedback will help to refine the kinds of services, functions and deliverables (reports) that will help make the portfolio management offering better. Depending on your organization’s culture, you may solicit formal or informal feedback. The results should be a validation of what’s working and adding value, and what could be done better. What you do with the results is what will bring back customers to your portfolio table.
Ensuring that you have a follow-up process for any of the services your portfolio team offers will lend legitimacy and credibility. Just like you don’t want to eat off of dirty plates and torn table cloths, stakeholders want accurate reports, timely meetings and follow up to unanswered questions. Continuing to ask, “Is this helping you to make decisions?” or “Does this incite the correct behavior?” will help keep the table clean and ensure repeat customers.
Don't forget to leave your comments below.
Cindy Lee Weber is a highly motivated, dedicated and passionate project management professional experienced in both corporate and small business cultures. Her focus on maturing best practices, while providing practical solutions has been applauded time and again by clients.
Cindy believes in measuring success and provides strategic foundations for delivering on-time and on-budget implementations. She consistently leads large improvement efforts for clients, including detailed process improvement for governance, portfolio management process improvement, and process documentation and refinement. Her expertise includes: project management, project management office, portfolio management, project and portfolio framework and methodology, project management training programs, solutions implementation, and measures and metrics.
Cindy is a certified Project Management Professional (PMP) and an active member of the Project Management Institute’s Minnesota chapter
Controlling projects is a good thing. Controlling people is not. What does it mean to control projects, not people, and when have you crossed the threshold from controlling the project to micromanaging the people?
When you start telling people how to do their jobs instead of focusing on the results they create is usually an indication that you have stepped beyond the bounds of project control and into the realm of people control.
Creativity and innovation are magic wands. They endow projects with enhanced performance and new profit-making results. They spark creative genius and the potential for creating wealth.
Most innovation springs from a conscientious search for new opportunities. These opportunities exist both within and outside a project, organization or industry. Innovation opportunities within a project include:
I have written before about how critical it is to be a good team player. Regardless of your skills, you limit your growth and potential if you don’t play nice with others. We are taught from an early age to share, listen, use our magic words (yes and please), and never, ever bite. These basic principles are not just for 3 year olds. They should stay with you for a lifetime. I know there are some people who are just bad team players and others that only play nice with people of influence, like a boss or someone signing their paycheck. Although this post is a good reminder for them, it also relates to everyone. For most of us our intention is to be a good team player, but work stress and life in general get us out of our team player mode.
In the continuing drumbeat of bad economic news over the past month, there is a fundamental underlying shift on how this economy has impacted project selection and execution. This is also an excellent opportunity for the creative risk-taking PM to gain a career advantage and strengthen the role of the PMO in today’s companies.
Trend Number One: Companies want to do more with less
We have all seen this trend and unfortunately some of us may be among the casualties of this trend. I advocate that Project Management is more important than ever to fully understand how we do the basic package of work in business: the project. I want to be clear in this area: the PM must be a hands-on PM not an administrator. The company needs to have a cost and
History witnessed one man motivating half a billion people to follow his vision, implementing non-violence strategies, and executing architecture for ‘Quit India’ movement. I believe this commemorative piece of solution delivery (Indian Independence) crafted and led by Mahatma Gandhi a.k.a. Bapu (Father of the Nation) resembles to  following ways through which we deliver IT solutions.
- Stick to the Vision
During solutions delivery, it is easy to drift while moving toward deadlines. Drift happens if there are frequent changes in the vision due to imminent business challenges, as well as external factors. These changes affect scope and delivery timelines. Vision changes may also cause rework in affected project areas. Implementation of analysis, build and test strategies, and definition of knowledge transfer channels allow teams to stick to project or program vision. Bapu’s vision was precise (clearly defined), correct (non-violence strategy can deliver), complete, and conforming (to every citizen’s dream of a peaceful
I have blogged recently about Plain Language here. This was in the context of poor-quality RFP and bid-response docs. The basic premise: if you apply some basic Plain Language checks to your writing, quality will increase.
In this post, I wanted to look at the IT space to see how we can improve documented requirements.
As background, people like Tom and Kai Gilb argue for improving requirements quality by rewriting them in a notation (Planguage) that is measurable and testable. This is really great if your team is able and willing to adopt that approach. In most business organizations, however, it is a bridge too far. This is because Bas (Business Analysts) are not conditioned to translate informal English into mathematical statements.
If you are beginning to consider a move to more agile methods, you may be looking for a set of ‘best practices’ for agile requirements elicitation and agile requirements management. What you will likely find is many prescriptive and detailed ‘best practices,’ which I have personally found to be situational at best, and often just too much to consume for an organization new to the concepts. What I propose to offer in this post are a few ‘baby steps’ that can help an organization move toward an agile environment and prepare for some of the more prescriptive methods like SCRUM or eXtreme programming (XP).
When making a move toward agile methods, there are three main recommendations that I believe should be considered to prepare for a more agile requirements practice, and a team as a whole.
- Collaboration ─ While this is obviously a good idea in all methods of requirements management and all stages of a project lifecycle, it is an essential element to agile methods and agile requirements management.
- Embrace Change ─ This is almost a counter-intuitive step for many business analysts. To be agile in requirements management, we must acknowledge change happens, embrace it, and make it part of our process.
- Support of upper management ─ Becoming agile is an organizational change as much as a development practice, and without clear support from upper management, this change will be difficult, if not impossible.
Recommending good collaboration is a bit like recommending good work ethic; it seems as if it should go without saying. However, for organizations used to a very siloed waterfall method, real collaboration as a standard operating procedure may have fallen by the wayside. It can become easy in a waterfall method to simply over-document deliverables and blindly send them to the next team. In an agile method, an organization will begin to keep ‘living documents’ that constantly change and grow ─ this requires true collaboration and teaming. In order to include all members of the project team and stakeholders properly, an organization must not only take on more inclusive methods, but must educate all associated people on the use of the method, including management and stakeholders. If one expects individuals to be involved, the individuals must know how, why, and when they are expected be involved. Simply said, to create an inclusive method, all individuals associated with the project must feel and be encouraged to be involved. One simple step many larger organizations have found useful is the adoption of stakeholders’ terminology. Often in agile methods, we get very focused on the new names, terms, and roles ─ all at the detriment to collaboration. Many stakeholders will feel more comfortable with requirements, time periods, and project roles being expressed in their own terminology. This should be seen by the project team as a minor secession for the sake of greater collaboration.
Embrace Change. To many Business Analysts and Project Managers, this will seem counter-intuitive. As professional BAs and PMs, we have been taught to identify all requirements and lock down the scope. However, we all know change does happen, and what often defines the success of a project is how we deal with that change. Traditionally, an organization would manage this change with some sort of project or scope change management process, which gives a structure to altering requirements that are typically fully elicited. In agile methods, organizations acknowledge that change is constant in technology projects, and move to embrace that change. To make steps toward agility, an organization may need to change their requirements elicitation methods. The elicitation can begin with very broad requirements that outline a general scope, do some high-level requirements modelling, prioritize what has been captured, and prepare the team to change as needed. Once the broad requirements are documented and ranked, the team can then begin to add further detail to requirements in an ordered fashion. This means the stakeholders will give detail as it is needed, and the team will change documentation as details emerge. The stakeholders know their priorities and requirements will change, and the project team knows the project documentation is ‘alive’ and changing as the project moves on, and as the need for detail requires.
While the above-detailed steps are important ways to ease into agile, arguably the most necessary step is getting upper management support. The management lines for both the project teams and the stakeholders must understand the use of agile methods is an organizational change, and not just a development method. These management lines must fully comprehend the concepts behind embracing change, increasing collaboration, and the notion of practicing constant requirements prioritization. As with many successful organizational changes, the use of ‘on the ground’ champions of the new process are important, but a clear message of support by company leadership is imperative. A project kick-off that includes an executive saying a few words of support for the new methods and mentioning that management is watching for this to be a successful implementation will go a long way to drown out the voices of the detractors.
As an organization strives to become agile, it is important to remember to be agile in the implementation of agile. Meaning, only take on as much agile process and change as your organization can handle in each ‘sprint,’ or short change window; and only keep the agile processes needed to improve implementation of technology projects. Organizations can often lose focus of their underlying purpose for adopting agile methods, and begin to focus on ‘becoming agile.’ There is not a prize or reward that comes with completely adopting any particular agile method, so look to embrace the parts of agile methods you need to find your success, and question anything else — because that is truly becoming agile.
Don't forget to leave your comments below.
Kurt Solarte is a Managing Consultant working for IBM Australia in Sydney; focusing on Agile Development methods. Kurt recently spent eight years with IBM Global Business Services in the U.Ss as a Sr. Business Analyst; where he specialized in keeping business analysis alive and relevant in the agile delivery of eCommerce, web portal, and business analytics projects.
The potential benefits of a project management office (PMO) are numerous and well documented. However, many of the benefits never materialize. Take a look at PMOs over the years and you will see that many have restructured, dissolved, or constantly had to justify their existence during both economic downturns as well as high-growth periods. This is evidence enough that PMOs are not yielding demonstrable positive financial results. This churn often causes years of frustration for both the PMOs and the projects and departments they serve. Changing the way in which the PMO is chartered, works, and is perceived within an organization can ensure that it offers plentiful advantages for the entire organization.
Two Problem Scenarios…And Strategies to Solve Them
One: The PMO is spawned by an executive with a big problem