Voices on Project Management

> Back to Voices Home

June 2012 Archives

Tracking Project Management Trends

| | Comments (2)
Faced with sluggish growth and shifting market priorities, organizations are often tempted to latch on to whatever's being heralded as the next big thing.

But the smartest project players are going back to the basics, according to PMI's 2012 Pulse of the Profession report.

Over the next several weeks, Voices bloggers will address some of the project management trends identified in the report, including:  

Talent development: Looking to gain an edge in new markets, organizations are scrambling to ensure the right people with the right skills are allocated to the right programs. And Pulse of the Profession data shows a payoff for those organizations that get it right.

Among high-performing organizations -- defined as those companies with 80 percent or more of their projects completed on time, on budget and having met business goals -- 63 percent have a defined career path for project managers. Compare that to only 26 percent of low-performing organizations, defined as those with less than 60 percent of their projects completed on time, within budget and having met business goals.

Project portfolio management: A still-fragile economy spotlights the need for good project portfolio management, with more than half of respondents reporting its frequent use in 2012. Pulse of the Profession data also indicates that 72 percent of high-performing organizations use portfolio management compared to only 39 percent of low-performers.

Organizational agility: As organizations are forced to deal with ever-increasing market volatility, use of change management, risk management and iterative practices is on the rise.

Pulse data shows that 80 percent of high-performing organizations use change management techniques and 84 percent practice risk management. Plus, 40 percent of high performers use agile approaches in project management, versus 20 percent of low performers.

Benefits realization: Companies don't do projects because they can; they do projects because they deliver a strategic outcome. Pulse of the Profession data reveals that defining key objectives, benefits and expectations is the second-most important factor for project success.

Additionally, having sponsors who are actively engaged is one of the primary factors that lead to projects meeting an organization's business objectives. Organizations with active sponsors on at least 80 percent of their projects have a success rate of 75 percent, compared to the average 64 percent.

To discuss Pulse of the Profession on Twitter, please use #pmipulse.

Learn more about PMI's 2012 Pulse of the Profession.

Many organizations choose to implement specialty software products as a business solution. The benefits of doing so vary from filling critical gaps in a company's portfolio of solutions and services to enabling a quick response to new regulations, such as health and safety mandates.  

Never assume that because a solution is smaller in size, you can take a relaxed approach to risk management. With enterprise resource planning (ERP) solutions, success requires collaboration between the project manager and the software provider to manage risks.

Here are some successful tactics for risk collaboration with specialty software providers:    

1. Encourage leadership engagement.
While it is rare to meet a company CEO, it is likely you will work with the CEO of a specialty software provider. Early in the project, create a deep level of engagement between the leadership teams. For example, connect someone from your leadership team with the head of product development. An early leadership engagement will create a quicker path to resolve any issues.  

2. Gain high visibility during analysis and design phases.
During the early phases of a project, a high level of visibility will help you to avoid costly errors in later phases. Early visibility also results in a quicker path to understanding the overall solution. For example, conduct design sessions at the specialty software provider's office.  

3. Align methods and terminology.
Invest effort early on in the project to harmonize methods, phases, deliverable formats and milestones. Agree on the terms for completing a project phase, as well as common terminology. For example, define the difference between a customization versus configuration. When you agree on these things early on, it's less likely any confusion or miscommunication will pop up.

4. Make site visits.
Nothing is more effective than talking with a current customer about their experiences with a specialty software provider. These discussions create visibility to both best practices and challenges. Utilize this outside view to refine your project risk approach.  

5. Don't underestimate contingency.
Even if a specialty software provider is smaller than an ERP company, it will still have the same fundamental delivery risks. Using a straight percentage for contingency may not be sufficient. Discuss with the specialty software provider a special contingency allocation to manage risks.

Do you have any tactics for risk collaboration?

Work to Live or Live to Work?

| | Comments (5)
Working with multigenerational project teams has taught me that commitment is a common attribute for team members of every generation.

But every team member approaches commitment in a different way. Different generations place different values on pursuing work-life balance.

A strong work ethic is a characteristic of the older members of the project team, part of the silent generation. Members of this generation tend to want to work a reduced number of hours to be able to devote time to personal activities.

Baby boomers, the generation referred to as workaholics, consider work a high priority and greatly value teamwork. In my opinion, they are focused on their achievements and are willing to work long hours to achieve project success.

Generation X is good at controlling their time. This generation has a desire to control and set a career path, personal ambitions and work time.

Generation Y is driven by a strong preference for work-life balance. Many Gen Yers look for jobs that provide them great personal fulfillment.

In my opinion, one of our tasks as project managers is to find ways to shed the stress in our project team members' lives. Part of that is to better understand the work-life balance needs of team members from different generations.

To bring a better work-life balance to any generation, define more accurate project schedules based on flexibility, telecommuting and time off.

Tell us about actions you have adopted to meet project goals and still accommodate team members' work-life balance needs.

Maintain Control in Lessons Learned

| | Comments (2)
In a traditional lessons learned session that is conducted face-to-face, project managers know each person who is present and his or her role on the project.

But technology today affords us the luxury of being able to do many things online -- such as holding a lessons learned session. We can engage with people across the country or someone who may be sitting right next door. Regardless of where someone is located, we must maintain a cordial and professional manner when we interact online.
When you have dispersed project teams -- and even sometimes otherwise -- getting people to stay focused and not be disrespectful to others in a lessons learned session is a challenge.
To overcome this, set the rules for participating in the session. Make sure participants understand them and agree to them. These rules should include:

  • Respect. Allow someone to make his post without experiencing sarcasm, blame or degradation. Emphasize open, honest and polite communications. Project team members will develop an appreciation for each other, the project manager and their organization.
  • Treat people as if they are right next to you. Use a tone of courtesy that can be recognized in any language. Respect the person's time and keep posts brief. Do not veer off on other conversations -- stick to the discussion.
  • Put a face to a name. Many applications allow photo uploads. When someone responds, everyone can see who is participating in the discussion.  
Setting the right tone in these sessions can lead to so many other opportunities. For example, when good feelings are engendered, it helps to build your team and other business relationships. You can learn more about each person, such as associations they may belong to or networking contacts that you can use for future collaborations and project guidance.
When you maintain control of the meeting and employ general courtesy, it keeps the discussion flowing and ensures everyone gets the information needed about lessons to be learned.
How do you maintain control in lessons learned sessions?

There's No 'Root Cause' in Project Failure

| | Comments (1)
"Complex problems have simple, easy to understand, wrong answers."
-- H. L. Mencken

When a relationship with a key stakeholder breaks down, or there is some other failure in your project, it's tempting to assume there is a 'root cause.' We think that by finding and fixing this key factor, the problem will be resolved.

Many tools help find the root cause and these tools work for simple problems. However, they are dangerous to use in complex systems.

The '5-Whys' approach assumes that each presenting symptom has only one sufficient cause. By asking 'why?' five times, you can drill down to the root cause.

For example, say that your boss complains that her computer is not working. You see the plug is out of the wall socket. You replace the plug and solve the problem, right? Well, the answer depends on how you define the problem:

Problem: Lack of power. Solution: Replace the plug.
Problem: Lack of training or knowledge. Solution: Teach your boss about the plug.
Problem: Poor joinery design. Solution: Put the power points on the desktop instead of on the floor.

The '5-Whys' approach requires the right definition of the problem to start digging for a root cause. Even then, the approach only follows one line of thinking, which limits its ability to identify complex interactions.

When considering problems in socio-technical systems, such as stakeholder relationships, the assumption that there is a single event that triggers a chain of events that lead to a problem is false.

Most problems have multiple contributing causes. Each element is necessary but only when all of the elements are combined 'correctly' is there sufficient impetus to create the breakdown. When trying to understand failures in complex systems, like relationships, a different paradigm is useful.

For example, let's say you used a range of motivational techniques to help your team perform that have worked well in the past. This time, however, the team disintegrated, and productivity dropped. Chances are that the problem emerged from a confluence of conditions often associated with the pursuit of success. But in this specific combination, there was "trigger failure;" each item was necessary, but on its own or in a different combination could be more beneficial.

These unexpected outcomes are encountered because complex systems, like relationships in and around a project team, have emergent behaviors, not resultant ones.

Complex causes require subtle management. You need to be continually prepared for nonlinear behaviors where small problems can result in large and cascading failures.

Rather then resolutely applying your standard approaches, look, listen and 'tune-in' to your team. When a complex system reaches the tipping point and collapses into failure, it is too late. You need to feel the issues emerging and adapt to the changing situation.  

How do you detect failures in stakeholder management?

Read more about stakeholder management.

Project Management Knowledge Versus Technical Knowledge

| | Comments (10)
As project managers, we have to manage various tasks in multiple lines of work. At times, we operate from our technical background and impart that knowledge and expertise more than our project management knowledge.

There needs to be the distinction of when we use our "project manager hat" versus our "technical specialist hat."

Many project managers work in two common extremes: process focus or technical detail focus. This is common for junior project managers and for project managers who are new to an organization. That often happens, in my opinion, because those project managers haven't developed their management style yet or haven't adjusted to the organizational culture.

When the project manager thinks something is going wrong on a project, either with how someone is performing a task or the results of a deliverable, we often try to fix it. We do that with our strongest toolkit -- usually, that's our technical background. We often take over and hijack the task just to do it "our way," based on our experience.

Remind yourself that as a project manager, you have a different role as a leader. You also can't be a technical skills expert for your team.

Realign yourself to the deliverables. Gain a clarity of the project goal, the project management approach you are using and your role in managing the given project resources.

Project managers can be quite connected and attached to the project outcome. But when you see an opportunity to improve something based on your technical expertise or what you would do differently, stay focused on your role, which is to deliver the project according to the business requirements, aligning with the business sponsor and the organization. Let your team handle their tasks according to their experience and expertise.

Do you ever rely too heavily on your technical expertise?

Read more from Dmitri.

9 Challenges in Project Management Clouds

| | Comments (0)
In my previous blog, I discussed the emergence of different project management clouds. Now I'd like to dive deeper into the challenges of those clouds.

Project managers may find themselves operating in two broad types of clouds:

Private: Private project management clouds are generally controlled, managed and hosted by an organization within a private data center. Restricted access to the cloud is for employees, customers or partners.

Public: Public project management clouds are made available in a data center on pay per usage model to the public, organizations, etc. The IT infrastructure and project management applications in the public cloud are usually shared across multiple customers.

Some issues and challenges that project managers must be cautious of with these project management clouds:

1. Vulnerability to cyber attacks

To avoid cyber attacks and privacy issues, make sure any project management cloud applications, technologies and infrastructures include built-in security features.

Compliance with security standards and policies is a must, but is also expensive. Factor this security cost into your budgets.

2. Software and interface application programming risks

Project management application software and APIs developed to work with other applications expose clouds to malware attacks..

Lack of security in project management applications and databases are vulnerable to cyber attacks and may cause leakage of confidential information. That leads to heavy penalties and loss of image or credibility of the cloud provider.

Additionally, network bandwidth issues and failure to meet service level agreements also lead to penalties and loss of credibility.

3. Disaster recovery and business continuity

Customers will face serious issues if cloud providers don't have strong disaster recovery and business continuity procedures in place. Cloud providers should have regular dry runs for these risks.

4. Legal issues and penalties  

Lack of knowledge of regulatory policies of various countries might lead to long legal battles. For example, some parts of the world consider it illegal if certain data is stored outside national borders.

For example, the European Union prohibits export of personal data unless the importing country "ensures an adequate level of protection," as certified by the EU Commission. Project managers have to understand the legal and regulatory policies of each country while using clouds.

5. Financial viability and stability of cloud providers

If a cloud provider is not financially sound, it could close its business or be acquired by another organization. Identify all the risks beforehand and be prepared with a mitigation plan.

6. Terms and conditions

Be completely aware of the terms and conditions mentioned in your contract with a cloud provider. Pay attention to security, data protection, IP protection, outages and business continuity.

If a cloud provider doesn't commit on these areas in the contract, find one who will.

7. Network incompatibility

Cloud computing networks built by customers may not be compatible with existing IT infrastructures of project management cloud providers. If networks aren't designed based on open standards, organizations will have integration challenges, so determine this beforehand.

8. Data security challenges

Review a cloud provider's data security measures to make sure project data is secure while transferring to/from cloud servers. The same goes for storing project data on cloud servers. Then perform regular audits on data security compliance.

9. Lack of standards

Cloud computing is an emerging area, thus the standards are also developing to have more interoperability.

Make sure a cloud provider has regular compliance checks for technology, service and security standards to upgrade their services.

What challenges have you faced within the cloud?

Read more from VSR.

Fill in the Blanks for Junior Project Team Members

| | Comments (5)
The other day, a member of my project team e-mailed me and proposed that we consider starting a new project. The new project would complement a project we are currently working on.  

Eventually, I learned that the project board had rejected this proposed project before. I discovered that a stakeholder who had pushed to start the project several times -- despite the fact that the board discarded it -- approached my team member, who happened to be a junior member and new graduate.

As a new member to our team, I had to explain the project selection process of our organization. The board selects projects from a business-oriented approach. Under this direction, projects produce business benefits that will contribute to achieve organization's strategic objectives. The proposed project did not fit this mindset, but as a new project team member, how could he have known?

I explained further to this project team member that in this mindset, project professionals must wear a business and technical hat. Depending on the situation, project managers must ensure that their project teams deliver projects that will produce the benefits and results that the organization is looking for.

This is just one example of how project professionals will need to be able to coach "multi" teams, especially those made up of new and young project members. You can't assume that everyone on the team shares your same knowledge.

Eventually, the junior team member understood why only projects that will help the organization fulfill its intended purpose should be selected. A few days later, we met with the stakeholder to ask for specifics about the project with regard to the organizational benefits.

How do you coach junior project team members when they are less knowledgeable?

About This Blog

Voices on Project Management offers insights, tips, advice and personal stories from project managers in different regions and industries. The goal is to get you thinking, and spark a discussion. So, if you read something that you agree with — or even disagree with — leave a comment.

All posts represent the opinions of the bloggers.

Follow PMvoices on Twitter

About Bloggers

Keep checking back because the voices for this blog will continue to grow and change to represent a variety of regions, industries and opinions.

Read blogger profiles

Voices Poll