Results tagged “Lynda Bourne” from Voices on Project Management

A Guide to the Project Management Body of Knowledge (PMBOK^® Guide) is developed by hundreds of volunteers to represent generally accepted good practices in project management. But is this enough?

There are already extensions to the PMBOK^®Guide for the construction industry and government that expand the basic framework to meet the needs of these sectors. Is there a need for extensions to meet the needs of different cultures?

The value of diversity and the challenges of managing culturally diverse teams was the focus of Tom Sullivan's feature article "Common Ground" in the October issue of PM Network^®. My column in the November edition of PM Network, "Culture Shock," highlights some contractual issues that impacted a major mine development. As projects and teams become more global, managing appropriately within and across cultural boundaries is a key project management skill.

Although there's no right or wrong in culture, different societies resolve challenges in different ways and use very different structures to communicate information within businesses and projects.

As PMI moves toward the start of the next PMBOK^® Guide update project, I would like to take the opportunity to discuss issues and challenges of managing projects in a cultural context. Do we need cultural extensions to the PMBOK^® Guide or is there more value in retaining it as a core definition of good practices that apply worldwide?

I've had my say in PM Network, now it's your turn to weigh in. Over to you!

Stakeholders must be important. A Guide to the Project Management Body of Knowledge (PMBOK^® Guide)--Fourth Edition has over 380 separate references to the word "stakeholder."

But the thousands of managers struggling today to meet stakeholder expectations may be interested to know that only a few years ago no one bothered. The whole concept of business or project stakeholders is a relatively new phenomenon.

The legal concept of a stakeholder is not new. Neither is the concept of "having a stake" in something.

One must also presume the concept of delivering a quality product to meet the needs of the end user, customer or client is not new.

In fact, many 19th century businesses had enviable reputations for customer service. Which leads to the question: What changed?

The origin of a business stakeholder in management literature can be traced back to 1963, when the word appeared in an international memorandum at the Stanford Research Institute. Stakeholders were defined as "those groups without whose support the organization would cease to exist."

The concept of business stakeholders was also a core part of the work on systems analysis in organizations conducted by researchers at the Tavistock Institute in London, England in the late 1960s and early 1970s. The concept has since grown from those beginnings.

During the last 30 years, the people and organizations covered by the term "stakeholder" have continued to expand and evolve. Stakeholder theory now includes the concepts of corporate social responsibility, organizational theory, systems theory, customer relationship management and governance.

And in the last few years, stakeholders have come to encompass anyone with an interest in or who is affected by the work of an organization or its deliverables, or as someone who contributes to the work or its outcome.

Now that the idea of a stakeholder has come of age in the project world, the new challenge is stakeholder relationship management maturity. Organizations that develop this capability quickly are likely to have a significant competitive advantage--at least until their competitors catch up.

I've been discussing stakeholders and communication for some time now without focusing on the key question: Why do stakeholders matter? Well, on most projects, stakeholders equate to risks.

There are a few risks that don't involve people--inclement weather, for example--but 90 percent of the risks on most projects are caused by one or more people:

•    Quality risks  almost always occur because people do not follow or not understand processes.

•    Design risks are usually the result of people not communicating.

•    Time and cost risks typically tie back to the performance of people doing the work.

•    Even inclement weather is influenced by people's perceptions--what's deemed "too wet to work" in a temperate climate may be seen as okay in a tropical monsoon climate.

People also determine if a risk is acceptable or not. Whether a risk is perceived as acceptable or not is 100 percent inside a person's mind.

As project managers, our job is to reduce risks to a level that gives the project the best overall chance of success. Yet extreme risk aversion will kill a project more effectively than a gung-ho attitude.

Of course, what constitutes a sensible level of risk is totally dependent on the perceptions and risk attitude of your key stakeholders.

That's why a central part of effective stakeholder management is ascertaining the risk attitude of your stakeholders. And then you must either adapt the project to fit within these parameters or provide the necessary information to help the stakeholder change his or her perceptions of what is acceptable.

The more that people feel they understand a situation, the more willing they are to accept risks.

Similarly, if you have a trusting relationship with someone, you're more likely to rely on their capability to safely manage risks on your behalf.

The most useful risk management strategy you can use on your project is effective stakeholder management supported by good communication. What has your experience been?

Everyone is talking about stakeholders these days. Surprisingly, this has not always been the case. The modern concept of stakeholders seems to have emerged from the work of the Tavistock Institute in London, England in the late 1960s and early 1970s.

Forty years later, the concept of stakeholder has expanded to include all of the people and organizations that have a real or perceived '"stake" in the project or its outcomes.

A Guide to the Project Management Body of Knowledge (PMBOK® Guide) breaks down a stakeholder as a person or organization that:

•    Is actively involved in the project
•    Has interests that may be positively or negatively affected by the performance or completion of the project
•    May exert influence over the project, its deliverables or its team members

In my work on mapping and managing stakeholders, I have found it important to expand on this basic definition to understand the "stake" of the stakeholder. This helps determine the best way to engage with them.  

Here are some of the different stakes a person or organization may have (most have more than one):

Interest: To be affected by a decision related to the work or its outcomes

Rights: To be treated in a certain way or to have a particular right (including legal or moral) protected

Ownership: To have a legal title to an asset or a property

Knowledge: To possess specialist or organizational knowledge needed for the work

Impact or influence: To be impacted by the work or its outcomes, or have the ability to impact (or influence) the execution of work or its outcomes

Contribution: Relating to the support or assets including the supply of resources, the allocation of funding, or providing advocacy for the objectives of the project

Once you understand the stake the stakeholder is seeking to protect, profit from or enhance, you can structure your communications to let the person know you understand their hopes or concerns. From this starting point, you're in a much better position to manage the relationship to the benefit of both the project and the stakeholder.

My last post touched on stakeholder attitudes. Attitude is derived from perceptions--in this context, the stakeholder's perception of the project and how its outcomes will affect the stakeholder's interests.

Fortunately, perceptions are negotiable and can be changed by effective communication. Change perceptions and a change in attitude will follow.

In my research, I considered two key dimensions to attitude:  
1.    How supportive or opposed the stakeholder is toward the project
2.    How receptive the stakeholder is to communication from the project team

Although receptiveness may seem less important, you cannot change a stakeholder's level of support if they refuse to communicate with you.

Levels of support can range from active opposition to active support. For each of the important stakeholders, the project team needs to understand the stakeholder's current level of support and then determine a realistic optimum level.

Exactly what that realistic optimum is varies. For example, environmental activists can never be realistically expected to support a new road through a wilderness area. The realistic optimum may be passive opposition and a communications plan developed to negotiate an outcome that the environmentalists can live with.  

Your project sponsor should be an active supporter. Communication needs to be planned to engage the stakeholder in actively supporting the project.

That means open communication. If the stakeholder is unwilling to communicate, ways need to be devised to open channels. This may involve using other stakeholders in the network around the project to open the communication, changing the way you communicate or just plain persistence.

Only after communication channels are open can you start to listen to the other person and understand their needs, concerns or ambitions. Once these are known, you're in a position to either explain how the current project meets those needs or consider risk-mitigation strategies to modify the project to reduce issues and enhance opportunities.

The whole point of stakeholder management is to optimize the overall attitude of the stakeholder community to allow the project to succeed.

A very significant proportion of the risks around most projects are people-based. The only way to identify, manage and/or mitigate these risks is by effective two-way communication. More on this later.

Any project team will have far more stakeholders to potentially communicate with than they have either the time, money or people to manage. But selecting the right stakeholders for a sustained communication effort in a project is not simple and can be a very resource intensive process.

My research over the last 10 years suggests a three-phased approach works best.

One: Identify the stakeholders and figure out what you need from them and what they want from the success (or failure) of the project. This is called 'mutuality'. If you can show the person they're likely to achieve at least some of their aims, they're far more likely to provide you with what you need from them.

Two: Work out which stakeholder is most important. This requires assessing at least three aspects for each:
•    How powerful is the stakeholder? Can he or she close the project down, force change or do they have little direct impact?
•    How much effort is the stakeholder likely to invest in asserting their position or 'rights'? Some stakeholders will go to almost any lengths to assert their position while others are really not that interested.
•    How close is the stakeholder to the project? People actively working on the project have more impact than those who are relatively distant.

Three: Determine the attitude of each important stakeholder towards the project and how receptive they are to your communication.

Now you have the information needed to focus your communication efforts where they can achieve the greatest benefit. People who have a supportive attitude simply need 'business as usual' communication. On the other hand, important stakeholders who are assessed as having a less than optimal attitude may need heroic communication efforts to change their views if the project is going to succeed.

And always remember: People change. Reassessing the stakeholder community on a regular basis helps ensure the communication plan is working or if it needs changing.

More on this soon.

My last post highlighted the challenges of designing a project communication system that works. Now I will try to suggest a few solutions.

To quote Peter Taylor's book, The Lazy Project Manager, "Reporting is not communicating." Executives don't have time to read fantastically accurate and detailed reports--people are simply too busy to take that kind of deep dive.

But at least some of that detail is important.

My suggestions to resolve this conundrum are:

•    Separate push and pull communications. Make the detail available in a repository such as a project portal) where people who need the detail can easily retrieve it (pull). Anything you send out (push) should focus on the highlights and information that requires action.

•    Separate history from future. Reporting what happened last week is of no value to the project unless it contains information that will influence future decisions. Historical data is needed by accountants and business administrators. project leaders and team members need information that is forward-looking, focusing on what might happen in the future and what needs to be done to improve the situation.

•    Focus on the needs of the receivers. Make sure you give your audience the information they need to help make the project successful. Team members need to know what work to do in the next week or two. Managers need to know what they have to decide.

Achieving this type of communication requires planning and information design. Each element of the overall controls system needs to be elegantly designed to support both management decision-making and the work of the project.

More importantly, the communication effort needs to focus on the important stakeholders who influence success: both internally to leaders within the team and externally to decision makers and influencers. (More on this later.)

And remember Cohn's Law: The more time you spend in reporting on what you are doing, the less time you have to do anything. Stability is achieved when you spend all your time reporting on the nothing you are doing.

Describing scheduling, earned value management (EVM) and financial management as "project controls" is, I would suggest, dangerous!  

The steering mechanism on a car is a control system. You move the steering wheel, and the front wheels turn and if the car is in motion, its direction of travel is altered. Control systems cause a change.  

Altering the duration of a task in a schedule, or calculating the current cost performance index and estimate at completion for an EVM report changes nothing. All you have is new data.

If the data is going to cause a change, it needs to be communicated to the right people. They need to receive, understand and believe the data--this changes the data into information. Then they need to use this new information to change their future behaviors.

This is a communication process. The challenge facing schedulers and other controls staff is recognizing their primary role is communication not controls. Certainly they need to be able to gather and process information effectively but this is wasted effort without equally effective communication.

Other challenges include:
•    Identifying the right people to communicate with--the project manger is only one
•    Formatting the data in a way that can be easily understood by the receiver. Without understanding, there will be no action.
•    Focusing the information on what matters in the future

No one can change the past and it's always too late to change the present. The only value a project control tool can offer is to influence future actions and decisions. This requires making schedules, cost plans and the like as simple as possible to improve communication and facilitate understanding by the project team.  

Only after the project team fully understands the information can you expect them to use the information to make wise decisions about future actions.

In most organizations project managers need to be skilled in both communicating downward to motivate their project teams and communicating upward to influence their managers. Yet while inefficient communication with  team members comes with its own set of issues, ineffective communication with senior management may put the whole project at risk.

Senior managers today generally operate in "command and control" mode, and most organizational processes support this view. Despite theories of team motivation based on empowerment, delegation and job enrichment, control is still the favorite with most senior management.

Project managers need to develop the skills needed to advise upward effectively. In so doing, they must align the project's objectives with the organization's strategic objectives and, more importantly, ensure the key senior managers appreciate this fact and contribute to the project's success.

The key is helping your boss look good.

This can be achieved by providing good information and analysis for decision-making; never escalating a problem or issue without options and recommendations for a resolution; and always communicating in business language with an understanding of the manager's business drivers.

A cooperative, supportive relationship is a two-way street. Project managers need to earn the respect and support of senior managers by adopting a positive approach to communicating up the ladder. Some positive options include providing helpful notes to assist the manager deal with difficult situations, and providing a full analysis of the recommendations and options for resolving issues or making decisions.

Advising upward or helping your manager help you requires a long-term view. There is no silver bullet! You must build credibility over time by developing and maintaining a reputation for being ethical, efficient and open. And above all you must be an effective project manager in your space and a supportive team player in your manager's space.

One element missing in much of the discussion around project management is a focus on the key early decisions that determine the project delivery strategy.  

At the project level, strategic decision-making focuses on optimizing the way the project will be structured and managed. Choosing between using Agile or Waterfall, pre-fabrication or on-site assembly, won't change the required project deliverables but will have a major influence on how the project is delivered and its likely success.

One size does not fit all; simply following previous choices ignores opportunities to enhance the overall probability of the project meeting or exceeding its stakeholders expectations.

Some of the key steps in designing a strategy for success include:

•    Familiarization with the overall requirements of the project and its stakeholders
•    Determining the key elements of value and success for the project
•    Outlining the delivery methodology and getting approval from key stakeholders
•    Developing the project's strategic plan based on the available know-how, resources and risk appetite of the stakeholders (including the project management team)

The problem with implementing this critical stage of the overall project delivery lifecycle is that it crosses between the project initiators and the project delivery team. Both parties need to be involved in developing a project delivery strategy that optimizes the opportunity for a successful outcome.

Unfortunately, the opportunities to engage in discussion and planning for project delivery are difficult to arrange. Frequently contract documents effectively prescribe a delivery process, and/or the client and senior management don't know they need to be engaged at this stage of the project lifecycle.

I suggest that project managers and project management offices start focusing more on the project delivery strategy during critical early stages of a project. What has worked or not worked on your projects?

The Agile community has some good ideas to pass down to conventional project managers, including:

Customer Engagement
While it may not be possible to iterate the building of a piece of machinery, engaging and explaining to the customer in their language--no jargon--what's happening will highlight issues early. If the customer doesn't like something, the sooner you know, the better.

One of the key tenets of Agile is to engage effectively with your customer and end-users, understand their needs and problems, and then deliver an effective solution. This requires regular and effective communication, openness and accountability, and a good measure of trust to support robust relationships between the project team and their key stakeholders. It's a pity so many project managers put their energies into fighting the client rather than collaborating.

Going Light and Lean
Those are hardly new ideas, but they've been embraced by the Agile philosophy for a good reason: They work. Lean was developed by Toyota as a manufacturing philosophy and has been adapted to many other areas. Some of its key principles--such as minimizing unnecessary movement, simplifying process and continuous improvement--have huge potential in project management.

Light is focused on the minimizing unnecessary overhead. Complex plans and processes should be simplified, but only to remove excess complication, not to remove core requirements.  

Slimming down the project management overhead to its optimal level is probably the easiest way to free up the resources needed to engage your stakeholders more effectively and is definitely supported by the A Guide to the Project Management Body of Knowledge (PMBOK® Guide).

For more information, see Light Versus Lean -- Steps to Improve Project Efficiency from PMI's Community Post.

A Guide to the Project Management Body of Knowledge (PMBOK® Guide)--Fourth Edition has nine technical knowledge areas plus the overall integration processes.

By aligning these processes to the Agile delivery methodology, effective project management will enhance the probability of success. But you must recognize the processes are applied differently.  

Some of the areas that need an Agile approach include:

Project Scope Management
Traditional project management expects scope management to define the output. The final outputs in an Agile project should be defined in terms of achieved capabilities--how the capability will be achieved will be discovered along the journey.

Change control will be more challenging, as is configuration management. The overall project needs a really good systems architect to keep each iteration or sprint focused on contributing to the big picture.

Project Time Management
In an Agile project, scheduling and workflow become closely aligned. The overall system architecture optimizes the sequence modules needed to be built in to allow progressive testing and implementation of capability.

This defines the schedule. Scheduling should be at a much higher level; each sprint is likely to be a single activity of one to two weeks' duration.

Project Cost Management
Agile projects should be based on either a cost-reimbursable system, or the client accepts scope is a variable based on achieving the maximum improvement possible for a pre-set budget. This is a totally different philosophy to traditional project governance.

Project Quality Management
This is probably easier under Agile. Quality is continually assessed by the involvement of the client and the iterative release of modules to production.

Project Communications Management
The level of trust needed to run an Agile project is much higher than a traditional project. Effective communications in all directions are essential.

Project Procurement Management
Agile works in a collaborative partnering space. In the engineering world these are called alliance contracts. Traditional contracts do not support Agile delivery methods very effectively.

More later....

This is a continuation of the post Creating Trust in Agile.

Agile advocates (AAs) need to understand their key stakeholders and empathize with their perceptions, fears and requirements. Yet far too many technical managers see this as unnecessary hard work--and then they wonder why their projects end up unsuccessful.
 
Forget the jargon of "sprints" and "iterations." Communicate in your stakeholder's language. As an Agile project is progressing through its cycles, what benefits are being delivered and how can they be measured? What contingencies are in place? What real progress is being made from the business perspective?

Mind you, this is probably good advice for 90 percent of IT and technical projects. The challenge facing AAs is they don't have detailed plans and traditions specifications to benchmark progress against. New ideas need to be developed.
 
AAs should also create ways of managing and reporting risk, scope, cost, time and quality--not from the technical in-team perspective but from a senior management perspective.

The essence of Agile is flexibility and change. The traditional way of dealing with these issues is by measuring the current variance from a predetermined baseline. The issues are no less important in Agile. They just have to be managed and reported differently. The challenge for AAs is developing effective ways of communicating how they are being managed to their senior management.
 
Finally, AAs need to have ways of differentiating problems suitable for Agile solutions from those that need a different approach. Agile is not a cure-all for every project and problem--senior management knows this and AAs need to focus on areas where real value is created by the methodology.
 
I'm not an AA. So I'll leave it up to the Agile community leaders to work out a solution ...

Over to you for comment!
 

Trust--backed by skilled developers--is the core element of any Agile methodology. Within the project team, the trust is relatively short term and the model is trust, but validate.

The sub-teams are trusted to build a module in a short sprint of some form and the results are validated. Where a paradigm shift in trust is needed is between the organization's senior management and the Agile project leadership.
 
Traditional project management grew in an environment where the triple constraints of time, cost and output could be clearly defined early in the project life cycle, and certainly well before major funds were committed. For example, builders would tender on a reasonably complete set of design documents and offer a firm price and time.
 
The concept of predictability flowed into Waterfall; senior management expected a defined design, backed by cost and time estimates before committing to the project. This approach does not work very often but sits comfortably with the "command and control" management paradigm most organizations adopt.
 
An Agile approach to problem solving is quite different. The Agile team wants to be trusted to work with the product's end-users to craft a solution over a period of time. They are saying to senior management: "Trust us to come up with the best outcome. We'll know what it looks like at the end."
 
With the right level of two-way trust, senior management can use Agile to maximize value. Essentially they can guide their teams using one of two approaches:

We want the biggest bang for our buck. You have X budget and X months to do the most you can. We trust you to spend our resources wisely to achieve the greatest value.

We need this regulatory requirement embedded in our systems by X. We trust you to deliver the required change in the most cost- and time-efficient way.
 
In both scenarios the Agile team is trusted to craft the optimum solution working with the end-users. The challenge is developing this level of trust. Unfortunately, even where change is desperately needed, it rarely occurs. In Leading Change, J.P. Kotter suggests over two-thirds of change efforts fail. Clearly, building the trust needed to allow the benefits of Agile to be realized will require some serious project management discipline.
 
To be continued ...

Editor's Note: This post is part of a continuing discussion on Agile. View Lynda's recent entries.
 

Over the last week or so, there seems to have been a flurry of activity in the blogosphere discussing Agile and waterfall software development, A Guide to the Project Management Body of Knowledge (PMBOK® Guide) and project management. This is an important debate.

A letter in the Feedback section of the March PM Network said Agile is not a project management methodology--I agree. Waterfall and various forms of Agile are definitely software development methodologies, not project management methodologies.

However, we can learn a lot with an open dialogue in both directions.

One common misconception among IT professionals is the assumption that the PMBOK® Guide approach to project management and the waterfall software development methodology are synonymous. Nothing could be more wrong.

Certainly you can manage a waterfall development using the PMBOK® Guide processes but nothing in the PMBOK® Guide mandates developing a fully detailed project plan before starting work on development. All the PMBOK® Guide requires is the current phase is planned before starting work. This is absolutely compatible with the Agile approach to iterative development.

Another misconception is that any new software development is automatically a project. Projects are temporary endeavors--this means temporary teams. If your IT shop is set up with stable teams working on a prioritized list of jobs using scrum or something similar, it is far more likely to be operational work rather than project work.

With these misconceptions cleared, there seem to be three key areas for discussion. (Your comments will be welcome leading into some future blogs.)

What are the differences in the way project management processes are applied in an Agile project compared to a waterfall project? Some thoughts:

•    The need for a much lighter "touch" managing an Agile project
•    The need for a higher level of trust in managing Agile teams
•    The need for robust change management and configuration management to track the evolution of the Agile project
•    The critical importance of developing the correct strategy and architecture at the beginning of the Agile project

Can traditional project management learn from Agile? Some of the trends in Agile seem to have wider application in any project involving knowledge work, including:

•    The need to trust knowledge workers more than manual workers
•    Success measured by customer satisfaction rather than quantitative outputs
•    The need to keep the client involved

What triggers the choice between operational maintenance and development versus projects and waterfall versus Agile.

More later.

The Asia Pacific Global Congress 2009 has ended, but I would like to share my overall impressions. The congress was definitely less crowded than last year in Sydney, Australia. A symptom of the tightening global economy, but paradoxically, this probably made the event more enjoyable.
     There was time and space to meet and talk to interesting people, the quality of the papers was exceptional, and the social events entertaining and interesting.
     Here are some of the highlights:
•    Young Min Park's paper suggesting many of the processes in A Guide to the Project Management Body of Knowledge Body of Knowledge (PMBOK® Guide) were applied 200 years ago in Korea for the building of the Hwaseong fortress. This paper clearly demonstrated projects have been around for millennia.
•    Patrick Weaver's paper on improving schedule management. He linked a clear understanding of the history of scheduling to the emerging views of projects as social networks and temporary knowledge organizations to suggest improved ways of using a schedule to influence future team actions and decisions.
•    The Tastes of Malaysia reception--the food was interesting, the displays of local culture and music fascinating. And watching the dozens of project managers armed with wooden mallets hammering disks of pewter into bowls to take home was a sight to remember. What is it about us project managers that makes bashing something with a large hammer so attractive?
     A final observation: Despite their similarities, the various PMI global congresses are definitely developing a flavor of their own:
•    The North American congress is impressive in its size, scale and power. Too much to do, too much to see and thousands of people. Total exhaustion at the end.
•    The atmosphere at the Europe, Middle East and Africa (EMEA) congress feels more collegiate, cultural and measured. Delegates seem intent on gaining the maximum benefit from their time at the congress right through to the last session on the last day.
•    The Asia Pacific congress seems more fun. There is a huge range of cultures present and conversations ebb and flow, people introduce themselves to strangers, thousands of business cards are exchanged and at the end everyone has a new network of friends.
I would recommend spreading your wings and planning visits to congresses outside of your region if time and expenses allow. You will definitely see different aspects of our profession.
     This congress has been fun, but now I have to get ready to work. I'm presenting a SeminarsWorld^® workshop.

Editor's Note: Read more about the PMI Global Congress 2009--Asia Pacific on PMI.org.