Friday, September 14, 2012

Seven Habits for Highly Effective Project Risk Management

When it comes to project management, over the years, the role of the Project Manager (PM) has evolved. Every project, large or small, comes with its own set of risks. As competition for bids increases, the ability to anticipate, acknowledge and create an actionable plan to address these risks becomes one of the most important elements in a capital project proposal.

For a long time, the PM position was highly focused on just the individual’s technical expertise. This is no longer the case. With the acknowledgement that project risk management is a crucial component of any undertaking, comes the increased awareness that on-time completion and remaining within budget is more about the successful orchestration and facilitation of others, than it is about technical knowledge.

What does that mean exactly? A report on the subject entitled “The 7 Habits of Highly Effective Project Managers” breaks down the habits that today’s successful PMs must learn in order to take their capital projects to the Best in Class level.

1) Be proactive: Anticipate potential problems and put an early warning system in place. This should include a detailed project plan, good cost accounting or production reports that show historical performance and a well-prepared timeline to monitor schedule risk.

2) Forecast completion: Begin a project with the end in mind. Firms are always looking at the forecast of the cost at completion and ensuring project trends are headed in the right direction. Setting key performance indicators via a dashboard or summary report is a great way to capture a picture of a project’s status at any time.

3) Prioritize the critical path: Be able to identify key items that need immediate attention and which do not. Set milestones for issues that have come up frequently in the past, for example, complications during the closeout phase of a project. Project risk management software is an easy and effective way to do this.

4) Collaborate: Effective PMs know how to connect people to solve a problem or complete a task. Because there are so many off-the-shelf project risk management databases that provide visibility throughout the organization, there is no excuse for everyone not to be on the same page.

5) Communicate often: Know how and when to communicate in the most effective manner. If it’s through email, in person, or both, establishing frequent and consistent correspondence will prove crucial to a project’s success.

6) Be accountable: The most successful PMs are so entrenched in their projects that any problem is their problem. The onus can’t be placed on anyone but the PM if a project is unsuccessful. This accountability can be achieved more successfully when senior management is actively involved in periodic, rigorous examination of the job’s status.

7) Continuous improvement: Best in Class project leaders are constantly looking for ways to improve. Frequent analysis of how well they are doing and how they might do better is paramount to continued success.

So there you have it: seven simple habits that will aid in effective project risk management – and the keys to make or maintain Best in Class status.

Article shared from The PM Coach.

About Chris Bell:

Chris Bell
Having collaborated with technology titans such as Geoffrey Moore, Marty Cagan, Phil Meyers, and Keith Ferrazzi, Chris brings life and energy to technology and business topics such as Enterprise Risk Management (ERM), Project Portfolio Management (PPM) and Governance Risk & Compliance (GRC). Chris is passionate about leveraging technology and is often found on the speaker circuit sharing innovative strategies to solve everyday business challenges. He is also a published author of many articles, whitepapers and books including EVM for Dummies.

Chris leads marketing strategy, brand strategy and marketing communications for Active Risk. He holds a Bachelor of Science degree from Mansfield University, and has completed graduate work at Boston University, Oklahoma State University.

Requirements Gathering in Project Management : Not Enough if not Prioritized or Ranked

This is a must read article by Gratien Gasaba on collecting project requirements, and most importantly, to keep perspective when collecting requirments. She writes for PM Hut:

“If you don’t know where you are going no road will take you there”.

To ensure that one is on the right road one needs to know where this road goes. But it serves for nothing if you don’t know where you are going. Assume you are in a bus station. You may be informed that bus number 1 will take the road to place A, bus number 2 to place B, bus number 3 to place C, etc. What criteria do you use to choose a right bus and to ensure you don’t get lost? The necessary and sufficient criterion is to know where you want to go. In the above illustrative particular case, if you want to go to the Place C, you will take the bus number 3 and exclude from your choice all other buses. In other words, if conductors of bus number 1 and bus number 2 try to convince you to take their respective buses, you will reply by a strong no, while to the conductor of the bus number 3 you will reply by an exclusive yes followed by your long strides toward the bus number3.

I have seen several project managers and project staffs complaining that the project beneficiaries are too inquisitive to the extent that it is impossible to know what they need. Complaints of this kind are warnings that the project is heading to failure. They signal a lack of focus. But who is responsible to clearly define and keep the project focus? What is the starting point towards what should be the real focus? Where and how can one gets information on what is needed to be done?
This article attempts to answer the above questions and highlight the importance of collecting requirements and actors involved in this exercise.

Collecting requirements is project manager centered

It is the project manager’s responsibility to ensure all stakeholders’ expectations are well collected and documented. After all, project managers are also required to manage stakeholders’ expectations as part of communication management. These expectations may be related to the project management or to the product of the project. When collected requirements are competing, the project manager is responsible to balance them. In fact, one of the most difficult challenges for project managers regarding scope management is to balance competing requirements and rank them by order of importance.

As project manager, do you have project requirements prioritized and ranked by order of importance? If so, congratulations! It’s a good start. If not, beware you may not be focusing the project resources to the right end!

Read full article by Gratien at PM Hut.

Leading Indicators in Project Management

There are two areas where diligence is important on Projects – (1) Planning and (2) Execution. Let’s assume that planning is done as well as possible and we are now in the midst of running the project. What I often find is that projects turn yellow just before a deadline is due when the PM realizes they won’t hit the date. This is usually less than one week away which really doesn’t give the team much wiggle room to take action and correct the problem. That is why I am a big fan of leading indicators.

The one I think works best is what I call “schedule earned value” which gauges the progress of a project against its ability to meet the commitment. In the simplest definition earned value tracks how much work is performed (earned) against how much time or resources is used (burned) to determine trending. For example, if a project has burned 50% of the time (e.g. on day 20 of a 40 day activity) but only completed 33% of the work then it is fair to assume that work is behind schedule (instead of waiting until day 35 to determine that). You can also use cost as a gauge of burn rate but this is harder sometimes to track and may not be as evenly spread as schedule.

The best way to install this rigor is to set up interim milestones against the plan and track them closely. This way as we risk interim milestones we can still track our progress against the major goals. The key is to track at a granular enough level to be able to see trends before they become issues and set up actions to correct them.

Article by Randy Wills and Kerry Wills for PM Hut.

The 5 W's of Successfully Working in a Global Project

Due to the global nature of projects, nowadays it's quite common for project managers to have project teams that include members of different nationalities and cultures.

Rather than making positive or negative conclusions about a culture, project managers need to build awareness and understand that cultures exist relative to each other. The challenge is to determine the actions that will enable them to successfully manage projects and reconcile the relative differences.

Project managers should consider the five W's to successfully work collaboratively on a global project.

Who: Who is working on the project? Everyone. It is rare to find a stakeholder or team member working on a project that has little or no contact with people from a different culture of their own.

What: What skills do project managers need to develop that will make them credible in another culture's eyes?

A project manager may be fluent in one or more foreign languages, for example. While that will help him or her communicate with others, it will not give the project manager the understanding on how a culture understands deadlines or other aspects of business. Project managers must listen and observe while working in a global setting to learn these things.

Where: Where is there opportunity to learn? Project managers should interact with people of different cultures inside and outside of the business world to navigate through unfamiliar cultures. Next time an intercultural opportunity arises, seize the moment to observe, reflect and learn.

When: When is the best time to collaborate with a multicultural team? Select an activity where all or most of your team members participate, such as a project status meeting. Does every culture respect a set meeting time, for example? In some cultures, there are no written rules of time etiquette, and a single event can be interpreted in a multitude of ways.

Why: Why should you care about multicultural traditions? As a project manager, you will have to manage teams that are partially collocated and across time zones. You should be somewhat comfortable in foreign environments and cognizant of local customs to continue learning and effectively conduct projects.

Article by by Conrado Morlan for Voices on Project Management

Tuesday, August 21, 2012

Shifting Your Productivity Mindset

Have you ever lain awake trying to get to sleep, but you can’t turn your work brain off? Or you have a whole Saturday to get things done, but it’s as if your motivation walked out the door along with your attention span?

In order to accomplish something, you have to have the correct “brain” turned on. Whether it’s an at-home project or relaxing enough to avoid looking at your phone, you have to shift your mindset to accomplish these tasks. Phil Cooke, author of “One Big Thing: Discovering What You Were Born to Do,” shares with us some tips around driving productivity through shifting your mindset.

  • At Work: Some days you know exactly what you need to work on, and other days you spin your wheels. Is that because your leadership is unclear, or because the team dynamic has confused priorities? “Teams are great for brainstorming, research, and execution, but at some point, a leader has to make a decision,” says Phil. You can demand actionable direction, and find out who really makes the final decisions. “In military terms, a team can decide how to take the hill, but a leader has to decide which hill to take.”
  • At Home: It’s really easy to bring your work brain home with you. Getting dinner on the table is suddenly the same as pestering your team to deliver their weekly reports. Your kid setting the table is different from an employee sending you a time sheet. “Once you cross the door and walk into your house, it’s time to switch to what author Jim Collins calls ‘legislative leadership,’” says Phil. “Legislative leadership is still leader driven, but it’s softer, more open to opposing ideas, and works because of consensus, not command. From a productivity standpoint, home and family aren’t about to-do lists, they’re about relationships.”
  • Personal Time: Some people like to be really productive with their personal time, volunteering in the community, writing books, knitting clothes, or taking classes. Others want personal time to be for relaxing. And some feel they have no personal time, constantly shuttling kids to activities or coaching the little league team. Either way, there’s another shift in mindset here required to accomplish any goal. You have to be purposeful in what you want to accomplish, and that also means getting the tools you need. “If you’re on the go, this is where mobile technology can make a significant difference, because adaptability doesn’t mean inability,” says Phil. Your phone can keep you connected or allow you to multitask. Or no phone at all can help you relax.
You can be productive, but to accomplish everything from work tasks to relaxing, you have to change your mindset. Doing so requires flexibility, something you demonstrate every day. This is incredibly important in today’s shifting world. “The folks at Change Anything tell us that 83% of employees have been passed over for a promotion because management felt they couldn’t make the necessary changes to move to the next level in their career,” said Phil. Change is good for you, so take these tips to start shifting your mindset.

Article by Emily Jasper for

Managing Multicultural Teams

As project managers in a global environment, we are now more often expected to lead multi-regional projects. This adds the element of different cultures -- both national and organizational -- that adds can add complexity to projects.

Perhaps your experience is similar to mine when working with project teams in a global environment. My multicultural project team consists of senior stakeholders, a deployment team and a technical support team. All team members have varying experience in the organization, but also can come from very different cultural backgrounds.

There can be a struggle when starting a project in a culture that you are not familiar with. How do you bring everyone together to share a common vision and commitment on the project delivery? I have learned that I need to develop strong cultural competencies to manage a multicultural project team effectively and to establish connections with the team members.

I like to use three tactics when on-boarding a new team member from a different culture:

1. Explain the purpose and benefits of the project to help establish the bond between the team member and the project objectives. Stress the importance of his or her role and how his or her local experience and knowledge will benefit the project.

2. Discuss any concerns that the team member may have, such as with language or customs. This can also help break the ice and show that you understand how difficult cross-cultural relationships can be.

3. Emphasize what is important to you, whether it's work ethic or communication methods, and why it's important. Don't assume that all of your expectations are globally understood.

When I manage a project abroad, one of my preferred ways to build cultural awareness is by spending time visiting popular spots where the locals meet. For example, at restaurants, coffee shops, sporting events and shopping centers, you can observe customs, traditions and behaviors.

Your observations in those settings can help to answer your questions about the culture. But it's just not observation that will help you.  People are very proud of their cultures and customs and are often keen to help you understand them. This supports the need to build a rapport with your team, whilst also building your awareness.

It's also important to understand your own culture's norms and behaviors. That knowledge helps guard against interpreting another culture's behaviors in terms of your own unexamined expectations.

Article by Conrado Morlan, PMP, PgMP for Voices on Project Management .

The Role of Executives in a Lessons Learned Session

In a lessons learned or project review session, your attendees will usually provide feedback freely. Hopefully, they know the purpose of these sessions and their roles in it.

But what about when your sponsor or upper management is present? What are their roles?

Rather than shelter upper management from lessons learned, consider their value in these sessions. Don't have upper management viewed as attendees who just want to hear the rehash of problems that the team doesn't want to relive anyway. Nor should you have upper management included to be a part of the blame game.

Ask your sponsor and upper management to be open minded and supportive advocates in receiving feedback toward improvement.

Here are three ways to get upper management to engage:

Talk: You, the project manager, must engage upper management in the discussion. Review the timeline and other milestones that took place on the project. Upper management could talk about how the goals of the project and the team's successes intertwined with the strategic goals of the company.  The team would appreciate this perspective on the significance of their activities.

Listen: While some discussion points may not be pleasant for upper management to hear, their presence assures a level of impartiality to the team. Knowing someone from "up top" is listening reinforces the team's drive to be a part of a high-performing group. Getting to more favorable end results in future projects would become even more desirable for the team.

Share: Have your sponsor share comments about the purpose of the project and its greater use to the organization, the end users and the community. Have them elaborate on processes. Ensure early on that they recognize processes mentioned in the discussion that could be rewritten or are no longer necessary. This sharing will foster bonding with the team.

Article by Bernadine Douglas, PMP for Voices on Project Management .

Tuesday, July 24, 2012

A Different Mindset: From Project To Program Manager

As a project manager, leading a project to success provides a feeling of accomplishment. Having been successful at several projects, project managers could see becoming a program manager a likely career move.

But when PMO managers were asked about the most critical factors for success, developing the skill sets of project and program managers were an area of concern, according to PMI's 2012 Pulse of the Profession. As a result, many organizations will renew their focus on talent development, formalizing processes to develop competency.

In my opinion, developing a program management mindset is a key first step to successfully transitioning to a program management role. For example, moving from the linear world of a single project to the molecular world of programs can be daunting. Plus, you'll face the new experience of leading other project managers.

Here are some practices I have found valuable to adopting a program management mindset:

1. Think big picture
A common misperception about programs is when they are viewed as one big project. Keep in mind that a program is an interconnected set of projects that also has links to business stakeholders and other projects. Adopt a 'big picture' attitude to the overall program and avoid fixating on a single project's details.

2. Create a project manager trust model
As a project manager, you develop trust with individual contributors performing delivery activities. As a program manager, you have to develop trust with project managers. Create a common interaction framework with every project manager for progress reporting, resource management, etc.

3. Encourage project managers to say "so what?"
As a program manager, you will deal with additional reports, metrics and other information that you didn't experience as a project manager. Encourage your project managers to start dialogs with "so what" outcomes. This will get right to the direct impact on the program. Have them support these outcomes with relevant information from their reports, dashboards and metrics.

4. Establish credibility with business leaders
With programs, customers are typically in business functions. Immerse yourself and your project managers in their business. Training, site visits and status meetings held at business locations are good ways to immerse your team in the customer's business.

5. Develop long-distance forecasting skills
Forecasting several weeks in the future is satisfactory with a project. However, a program with projects moving at different speeds and directions requires a longer forecast horizon. Set your forecast precision in terms of months, not weeks. In addition, look for multi-project forecasting considerations such as holiday blackout periods and external project dependencies.

Article by Kevin Korterud for Voices on Project Management .

Wednesday, July 4, 2012

What does a Project Sponsor really do?

Your project sponsor is the key link between the project management team and the organization's executive management. An effective sponsor "owns" the project and has the ultimate responsibility for seeing that the intended benefits are realized to create the value forecast in the business case.

A good project sponsor will not interfere in the day-to-day running of the project -- that's the role of the project manager. But, the sponsor should help the project manager facilitate the necessary organizational support needed to make strategic decisions and create a successful project.

With respect to the project, effective sponsors should:

  • Create alignment. The sponsor helps keep the project aligned with business and cultural goals.
  • Communicate on behalf of the project, particularly with other stakeholder groups in senior management. The sponsor also communicates his or her personal commitment to the project's success on multiple occasions.
  • Gain commitment. The sponsor is a key advocate for the project. He or she "walks the talk" and gains commitment from other key stakeholders.
  • Arrange resources. The sponsor ensures the project's benefits are fully realized by arranging the resources necessary to initiate and sustain the change within the organization.
  • Facilitate problem solving. The sponsor ensures issues escalated from the project are solved effectively at the organizational level. This includes decisions on changes, risks, conflicting objectives and any other issue that is outside of the project manager's designated authority.
  • Support the project manager. The sponsor offers mentoring, coaching and leadership when dealing with business and operational matters.
  • Build durability. The sponsor ensures that the project's outputs will be sustained by ensuring that people and processes are in place to maintain it once the project completes its handover.
If you have a good sponsor, look after him or her. If your sponsor does not understand the role or is unwilling to fulfill the role, however, you need to speak up. Carrying on without an effective sponsor raises the probability of project failure and you as the project manager will be held accountable for that failing.

It's important to flag the lack of effective sponsorship as a key risk to the project. It may not make you popular, but you have an ethical responsibility to clearly define risks that need management attention.

Ultimately the organization's executive management is responsible for training and appointing effective sponsors. If this has not happened, as project managers, all we can do is help those sponsors who are willing to be helped and flag a risk or issue for those that are missing or unwilling to support "their project."

Article by Lynda Bourne for Voices on Project Management.

Project Risks + Proactivity = Success

Risk management as a best practice is critical to project success. It forces the team to consider the deal breakers on a project, and to proactively prepare and implement solutions.

PMI's recent 2012 Pulse of the Profession report found that more than 70 percent of respondents always or often use risk management techniques to manage their projects and programs and these practices lead to higher success rates.

Here's an example of how risk management could have saved a project:

A project manager oversees an electrical team that is responsible for installing electrical and audio-visual equipment. The construction and civil engineering teams hand over the completed and decorated site, ready for the final phase of the project. To the project manager's dismay, the projectors do not align with the screens, rendering them not fit for the purpose.

What went wrong?

The civil and construction teams had altered the dimensions of the rooms; the customer failed to communicate the changes to the electrical team. Assuming the project was executed according to plan, the project manger planned and submitted the electrical drawings based on the original dimensions of the room. These plans were made redundant when the room dimensions changed, which upset the equipment's position.

To correct the situation, the project manager drew and submitted new electrical drawings. The site's walls and ceilings had to be reopened to accommodate the changes, which caused delays and increased cost, rework -- and frustration.

Had there been a robust risk identification and implementation plan, they would not be in this situation. Too many assumptions were left unchallenged and risks pertaining to the many external dependencies were overlooked.

As part of this risk management, proactive communication with the customer and other teams should have been planned. For example, the project manager should have considered and asked questions about how the contractors and sites would be monitored and controlled. What would the frequency and type of communication be like with stakeholders?

There should have been an assessment of 'what if' scenarios. What happens if the deliverables are not as expected? What are the risks if there are problems with contractors? What is the impact of not having dedicated resources on the team?

These types of discussions and questioning would have alerted the project manager and team to proactively plan to manage the quality of contractor work and employ the necessary resource on the project team.

Article by Saira Karim for Voices on Project Management

Work to Live or Live to Work?

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.

Article by Conrado Morlan for Voices on Project Management.

Sunday, June 24, 2012

Why Projects Suceed - Articulating the Value of Project Management

Balancing Strategy and Tactics

By connecting the dots between tactics and strategy and creating a balance between the two, the successful Project Manager provides true leadership to team members, stakeholders and the executive sponsors. That balance is required for any project or campaign, as illustrated by one of my favorite quotations:

“Strategy without tactics is the longest road to victory. Tactics without strategy is the noise before defeat.” - Sun Tzu

Or as I like to paraphrase…

“Tactics without Strategy: a lot of running around. Strategy without Tactics: a lot of sitting around.”

OK, I’m not as poetic, poignant, or published as Sun Tzu, but you get my point. The successful Project Manager provides this balance for their teams and projects and ultimately ensures effective commitment management and value generation.


Driving “value” is only part of the battle for Project Management. Being able to articulate that value is crucial for successful Project Managers. Whether it’s motivating team members to participate in project activities, or getting stakeholders to pay attention to your project requests, describing the value of project management so that it is understood by stakeholders is a key to project success.

Get full article by Roger Kastner at:

More about the Author:
Roger Kastner is a Business Architect with Slalom Consulting who is passionate about raising the caliber of project leadership within organizations to maximize the value of projects. You can read more articles from the series on “Why Projects Succeed” here.

Is Project Management the New Quality?

In the 1980’s and 1990’s quality management seemed to be taking over the world’s organizations and businesses. It seemed quality improvement, kaizen, value added management, LEAN, six sigma and so on were all seen as the tools for helping organizations improve performance every year. A large number of the world’s best practice organizations led the way with massive investments in training, systems, equipment and culture change programs. It now appears that most of these organizations that were leading the charge to quality have largely led the retreat as well. Few organizations now seem to have highly paid Quality Managers, Quality Departments or Quality Systems as such.

In the 1980’s and 1990’s it was often said that organizations had to improve somewhere around 10% year on year just to stay relevant compared to competitors and constant changes in technology.
Constant improvement and prevention of errors, waste and mistakes, I believe, is built into most of us.

If that is correct then my question now is: If quality improvement was so vital to every organization’s success then, how is it happening now?

My answer is project management.

Organizations, both public and private sector have embarked on a huge project management kick and most don’t seem to realise it. A cursory review of job titles in the public sector has thousands of staff with project in their title. They could be project managers, project team members or project officers but most are not formally trained project professionals and don’t really do formal projects that would meet today’s definition of a project.

How did this happen and what does it mean for organizations?

I believe it happened because quality became too expensive, too difficult, time consuming and too risky to stick with and far too hard to obtain tangible results that could be directly attributed to the quality effort. You can have the greatest product in the world but people have to see the need to buy it and reasonably believe that it will produce the desired results. In the end after such a huge investment there had to be significant results and in a lot of cases these results couldn’t be put forward for all to see. The belief was no longer there.

In today’s climate it is much easier to sell executives and decision makers the concept of project management as a “go forward” type vehicle for most organizations. This has, just like quality management did before it, generated a support industry made up partly of zealots and believers established to support organizations through their project management transition. This means training, accreditation, materials and record keeping systems to accommodate them all. One of the other negatives is the amount of energy some industry insiders are happy to spend arguing/discussing the merits or otherwise of the various project management methodologies available and which one is “best”.

Amazing how wedded some people get to methodologies instead of being more interested in getting the best results. Reminded me of the old quality management days.
Progress down the project management road so far is pretty mixed to say the least. Catastrophe databases have appeared on the internet documenting some of the more spectacular project failures around the world.

This makes depressing reading.

The private sector and the public sector seem to be both struggling to successfully deliver major projects, especially IT projects. It almost seems at times that the projects are managing the people and not the other way around.

In this country, we have a public transport ticketing system that cost taxpayers more than the last Mars landing. We have a payroll database brought in at a budget of $40M that still doesn’t pay staff the correct salaries and has blown out to $400M so far and still going. There was a federal government initiative to encourage home-owners to get roof insulation installed in their houses to save energy. Included in the unintended consequences of this project were four fatalities including a number of young and inexperienced installers who tragically and unknowingly ended up in harm’s way just trying to earn a living. This project was obviously a rank failure as soon as the first person lost their life but it should be noted that professional inspections were then required for 50,000 dwellings and a further hundred or so houses burnt down as a direct result of the project.

It is the same overseas as well. There is a litany of spectacular project failures in driver’s license databases, stock market programs, travel systems, baggage handling systems, construction projects, disaster management restoration programs and now, more recently stimulus spending programs.
There is research that suggests that around 1/3rd of all projects fail in progress and are abandoned before they are finished. It also seems that roughly half of all projects come in close to double their original budget.

The research also suggests that around 1/6th of all projects come in on time and on budget.

Is this good enough? I think not.

What can be done about it?

Will project management eventually join quality management and the dinosaurs and be consigned to the history books?

Article by Stewart A Brown for PM Hut.

More bout the author:
Stewart A Brown is the Managing Director and owner of Blueprint Planning Solutions Pty Ltd.
Stewart holds a number of qualifications including Mechanical Engineering and Development, Quality Technology and Quality Improvement. Stewart earned a Graduate Diploma in Quality and a Masters in Business from Queensland University of Technology. In addition, Stewart has been trained by Nippon Light Metals in process improvement and has accreditation to deliver KAIZEN projects. Stewart has also delivered many training sessions using Value Added Management, Project Management, Decision Making and Process Improvement Tools and Techniques. Stewart was an accredited Team Leader for the Australian Business Excellence Awards and has also served as a team member for the Australian Mining Industry Safety and Health Awards.

Reacting to a Problem

Things go wrong in projects, that’s fair enough. Lets take it as read that your trying your best to identify, remove or mitigate risks (if not stay tuned for more articles on the ins and outs of risks soon). But what do you do when something goes wrong, something that you under estimated or just plain missed (and this happens to all of us.)

First things first you need to understand what the impact of the problem is. Not the running around waving your hands screaming everyone’s going to die sort of impact, but the sober, sitting back, emotionally removing yourself for a moment and analysing from different perspectives sort of impact.

To get started consider who is actually involved and try and put some numbers on them (it’s usually less then you expect), next figure out the ways in which people have been impacted and split people above out into these groups. Write all this out and you’ll soon have a pretty good idea of what the actual impact is and you’ll have calmed down and feel a new mastery over the situation! By completing this little exercise you’ll now have a well defined tangible problem against which you can plan out your actions.

Article by Pete Winn( for PM Coup

Wednesday, June 13, 2012

Project Management Knowledge Versus Technical Knowledge

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.

Article by Dmitri Ivanenko for Voices on Project Management

Tuesday, June 12, 2012

Change embrace it!

Change is nothing to be afraid of; in fact if it wasn’t for change, there wouldn’t be a need for project management.  Isn’t that what we do as project managers; manage change?  Yet often I have noticed that some don’t understand what they should do when change occurs in their project.  I believe the reason for this fear of change is because they react to change rather than plan for change.

The Doberman

A few years ago I was helping my son with his paper route.  I was driving him around the route because this one Sunday’s edition happened to be quite large due to the number of advertisements.  I remember watching him approach one particular door, but before delivering the paper, he made an abrupt turn and raced back to the car.  I saw fear in his face as he approached me and I asked him why he didn’t deliver the paper.  He informed me that there was a ferocious Doberman at the house and he was not going to deliver the paper.  Before I knew it, Dad was volunteered to deliver the paper.  As I approached the door, I discovered that the ferocious canine was indeed just a little Dachshund, a Weiner dog.

Four Keys to Managing Change

Just as my son was afraid of something he wasn’t expecting, we can be afraid of change if we are not prepared to manage that change.  Here are four key things to remember, which if followed will help us be prepared when change happens.

1.  Make sure there is a change management process in place.

Either the organization or the project should have a well defined change management process implemented so you will know what to do when change occurs.  The project manager needs to be able to understand, who approves changes, what steps must be followed to get that approval, and what mechanisms are required.

2.  Have a solid scope, budget and schedule defined.

This is critical because change can occur to any three of these constraints.  A shareholder can request additional scope be added to the project.  Management might decide to decrease the budget due to funding constraints.  The market might dictate the project needs to be delivered earlier than planned.  When these three constraints are well defined, you will have a baseline in which to measure the change.

3.  Analyze the impact to the project.

The project team, lead by the project manager, should analyze the impact of the change to the defined scope, budget and/or schedule.  This impact will be documented and presented to the decision makers of the project.

4.  Insist on a decision prior to acting on the change request.

Based on the documented impact and following the change management process, get a decision for approval or rejection of the change request.  Don’t make the mistake of acting on a change request prior to obtaining an approval from the decision makers.

As you follow these key recommendations, you will be prepared when change requests hit your project…and you won’t be afraid.

Article by Mark Phillipy (

About the author:

Wednesday, June 6, 2012

Nontraditional Ways to Get Feedback for Lessons Learned

When capturing lessons learned, feedback can come from anywhere. Don't dismiss comments because of how you receive them.

Consider that you may want to receive feedback from the quality assurance manager who's always on the run. Talking on a mobile phone while he or she is driving from site to site may be illegal, though.

Or consider the database administrator who transitioned off your project in phase one, who no longer has security access to the project, and is now busy on her next project.

So how do you get their feedback?

It isn't easy to reach out and receive the lessons your stakeholders may want or need to share toward improving the next project.

These two unconventional communication methods can be used to help in lessons learned:

  • Try a text or Twitter message. Texts and social media aren't only for the younger generation. But to use them, you must to be concise. You may ask your stakeholders to drop a quick message and provide more detail later when they may have more time. 

  • Host a blog site. Start by setting up categories to receive feedback on particular areas of the project, for instance. Using the categories will allow a better way to coordinate the comments, and give the stakeholders a fast way to respond.
In lieu of attending an in-person project review, receiving lessons learned material by other traditional methods could work as well. Contact a stakeholder by e-mail. Dial the person on the telephone. No matter what, reach out for feedback.

Article by Bernadine Douglas for Voices on Project Management.

A Project With No Project Charter?

Also known as the project initiation document, the project charter is a high-level document created at the start of a project and referred to throughout the project's duration. It is the foundation of the project, a basis for how the project can evolve. The charter should state the purpose, main objectives and vision for a project.

Many project professionals may consider the project charter as 'more documentation' or a 'mere formality.' But the truth is that if they start to consider creating a charter as a best practice, many problems or issues can be eliminated.

However, I regularly meet project managers that manage their projects without referring to or even knowing the existence of their project's charter.


Here are some reasons a charter is left out, based on my experience:

  1. Project management immaturity, lack of project approaches or poor project governance by the sponsor or organization. There's a lack of awareness for the need of a charter or formal authorization process.
  2. At project initiation, there are no clear measurable objectives or reasons for the project. Hence, there is nothing to write.
  3. The charter may have been written, but is filed away or lost within the organization's documentation system. This could be a symptom of high staff turnover or poor information systems.
  4. Requirements and other changes to the project deemed the existing project charter obsolete.
  5. The project has been initiated or is continuing without real executive commitment. 
  6. The project is considered too small or simple to be chartered, so writing a charter is considered a 'waste of time.' 
  7. A charter may exist but contains information that is rigid. Details, budgets and milestones may be unrealistic and unachievable, and therefore not referred to.
  8. Alternatively, the metrics and information contained in the charter may be too broad and ambiguous and therefore not referred to.
However, without a charter, a project is headed for problems including:

Risk of diminished value and importance of a project, if its purpose and strategic benefit are not documented, agreed and formally recognized.

Delayed decision-making. Getting management and sponsors to sign off on things becomes difficult. There is no one to champion for the project and responsibility for it is passed around.

Difficulty managing expectations. Without a collectively agreed to charter, there may be frequent disruptions and disagreements from stakeholders. They will have differing intentions, opinions and understanding of the project's outcomes.

Risk of failure. When there is no clear, recorded statement of a project's goals, it's more prone to fail. The project charter includes the business case and other additions, which serves as a constant reminder of the project's vision, mission and critical success factors.

Lack of authority. The project manager will be plagued with problems from lack of authority to spend the budget, the ability to acquire and assign resources, and a general power needed to make day-to-day decisions and actions. This will also make it harder for the project manager to attract good suppliers, vendors and resources to work on the project. This can create a culture of dissatisfaction and apathy within the existing project team.

Subject to scrutiny, delay and bureaucracy. The project can expect numerous changes and deviations, which increase the risk of not delivering and reaching the projects goal. It could eventually become a financial burden to the organization.

Article by Saira Karim for Voices on Project Management

Tuesday, May 15, 2012

Strategy Execution

Sharing views on Strategy Execution. Project Management enables organizational initiatives to have a chance on success.

Monday, May 14, 2012

Writing a project scope statement

A ``Project Scope Statement`` is more than just a one or two line statement. If`done correctly, it will give a complete overview of the project. Heather Buckley explains:

One of the most important stages of a project is the writing a Scope statement. Getting this right means that you can avoid many problems and help the project flow. Your Scope statement should document as much as possible, as clearly as possible, and should make sure everyone involved is aware of what is expected.

Project Management Scope Statement

Get the project started by writing the
- Project name
- Project character
- Project owner
- Project stakeholders
- Project sponsors

The next step is to clarify the
-Project justification (reason for the project)
-Project requirements
-Project milestones
-Project deliverables

Make a note of anything that may constitute a goal related to the project.
Next, start to work our your project cost estimates – this information should be readily available to everyone who is involved in the project.

Make sure that everything you write is concise and clear starting with the project name. The name should describe what is expected during the life of the project – a well thought-out name also helps provide a vision of where the project is headed.

Next you should prepare a project charter to authorise the project, provide a high level overview and identify the main stakeholders. It should also identify the objectives or goals, and include any constraints on resources or time. The charter will be used as the focal point throughout the project life-cycle.

Project Justification

The project justification needs to be identified because this helps to give overall direction to the project; it should emphasise the final goal and identify a quantifiable measure of success for the end of the project.

Requirements and Deliverables

List the requirements of the project in your Scope statement. These will include objectives that must be met and may include any significant milestones or goals. Objectives need to be clearly identified and quantifiable.

Deliverables are usually associated with identified milestones in the project schedule they must be agreed upon by the project owner as well as the major stakeholders. Some deliverables might be a final product to be provided to the stakeholders. Again be specific, the more clearly you identify the deliverables the less chance there is for scope creep (the deadlines extending gradually but uncontrollably) to occur later on.

Cost Estimates

Try and be as accurate and realistic as possible. It is easy to underestimate and cause the project ot go wildly over budget.

Formal Acceptance Signatures

Once you have compiled all of the documentation in a clear and concise statement, the major stakeholders and the project owner need to sign off on it. A copy of the Scope statement should be provided to everyone involved. This is your chance to clear up any discrepancies and make changes where necessary.

Once the Scope statement is signed off, you now document the original agreement. If things change and the Scope does need to be increased for some reason then another meeting should be held so that signatures should be obtained again.


  • Provide detailed specifics
  • Use clear and concise language throughout
  • Avoid ambiguity
It is worth spending time on your Scope statement, you can save more time in the long run and minimise scope creep. Scope creep is often a significant cause of project failure.

Get your Scope statement right and you are well on your way to delivering a successful project.

Keep it simple

One way of looking at the role of a project manager is that of a person who leads a group of people through a complex set of tasks to achieve something out of the end of it.

One of the main challenges you’ll face is that it becomes very hard to deliver very complex things because people don’t fully understand them and consequently that makes them scared! Sounds silly but just watch the difference in behaviour of someone completing a known task and then watch them pick up a complex unknown project.

Assuming you won’t spend your entire career working with people who already know exactly what to do (if so you’re probably not needed!) your going to need to find a way to help people cope with the big scary unknowns.

The best advice I can give on this and I’m afraid this isn’t original is…

Keep it simple!

and if it’s already complex – Make it simple!

This is not really a prescribed tool so much as just something to remind yourself of throughout a project, but either way here are some examples…
  • Break out large projects into high level streams and phases and ignore the ones your not working on;
  • Break down something complex down with a top down approach into it’s component products;
  • Place work items onto a “future” list to deal with later (lists have a better memory than you do!)
  • Or just start simple and grow in a controlled manner – by delivering a very small project and adding to it over time!
Article by Pete Winn( for PM Coup.

Monday, March 26, 2012

The Power of Process: How Bad Project Management Kills Great Ideas

We suppose it’s not only a lesson from Business 101 but from Life 101: Only move on to the next step when the previous step is complete. A maxim of Aurelian sophistication it ain’t, but how many inspired ideas have you had to relegate to the cutting room floor and how much time has your organization wasted because of a failure to adhere to it?
Here’s how it tends to happen:
  1. Core team in charge of solving problem defines parameters and begins work.
  2. Potential solutions to problem hypothecated.
  3. Broader decision-making team consulted for input.
  4. Refinements made, brilliant solution identified and recommendation presented to broader team.
  5. Member of broader team who missed first meeting provides new, contradictory input.
  6. Refinements made, somewhat less brilliant solution developed and approved by broader team.
  7. Core team begins operationalizing solution in order to meet aggressive timeline.
  8. Solution presented to senior executive: a mere formality according to broader team.
  9. Senior executive whose time was far too valuable to involve in the initial process is underwhelmed by solution – especially when compared to those posited by significant others, tennis partners and themselves; provides new data that changes problem’s parameters; turns out to be actual decision-maker.
  10. Organization engages in several rounds of all-hands meetings, early-morning conference calls, late-night emails and general all-around inefficiency to develop, get approval on and begin operationalizing new, decidedly mediocre solution.
In our experience (yes, even the mighty Brand Culture Company has made a few rookie mistakes), this dysfunctional workflow is usually not the result of pure ineptitude – it’s the product of best intentions. People and teams tasked with solving problems usually want to do so quickly and cost-effectively. When the schedules, availabilities and responsiveness of more senior stakeholders threaten to slow progress, they often proceed anyway – optimistic that everyone will recognize a great solution in the end.
But everyone doesn’t simply recognize great solutions for two reasons:
  1. Senior stakeholders may possess information that is critical to solving the problem, or that they believe to be critical. If that information isn’t addressed, the stakeholders are unlikely to be supportive.
  2. All people like to be heard. If they haven’t had a chance to weigh in on a process early, they’re rarely hesitant to do so at the end.
Here’s what we tell ourselves whenever a client asks us to help them solve a problem:
  1. Let’s find out who the real decision-makers are.
  2. Let’s make sure those decision-makers can participate in at least one initial briefing and one round of feedback on progress.
  3. Let’s not present any recommended solutions until we’ve had these briefing and feedback sessions with all key decision-makers.
While it looks so simple and obvious on the screen, it isn’t easy to adhere to when schedules are tight and the demands on peoples’ time are many. But when we’ve done so successfully we’ve found it not only increases our chances of producing great work – it helps us work more efficiently as well.

Article shared from PM Hut.

This article first appeared on BrandCulture Company’s blog
BrandCulture is a brand, marketing and corporate culture consultancy headquartered in Los Angeles. The firm combines the disciplines of brand building and organizational development and to create strategy, communications and culture programs that help businesses create preference in the marketplace and drive performance among employees.

The Ten Commandments of Project Management

Over the years I’ve seen many attempts to construct the “10 commandments of project management”. I believe there is an element of cheekiness in this as it suggests a divinely inspired set of rules, wholly encompassing (or should I say holy encompassing) a complete project management experience. Chutzpah or not, I am going to give it a go as well. But before I lay out my own proposal I’d like to provide a quick overview of those who so bravely came before me, putting their neck on the line in the search of the holy grail of project management.

So here we go:

Michelle Young Cavanaugh published the following in TechRepublic in 2000:
  1. Thou shalt have a project with goals
  2. Honor thy project objectives
  3. Thou shalt commit to the schedule that management hath given thee
  4. Remember thy checkpoints
  5. Thou shalt delegate tasks to thy manservant or maidservant or staff
  6. Thou shalt create a picture of thy project schedule
  7. Honor thy team members
  8. Thou shalt commit thyself and thy team to the project
  9. Thou shalt document extensively and keep thy team informed
  10. Thou shalt encourage creativity
James M. Kerr published the following in ComputerWorld in 2006:
  1. Thou Shalt Narrow Project Scope
  2. Thou Shalt Not Suffer a Fat Team
  3. Thou Shalt Require Full-Time Business Participation
  4. Thou Shalt Establish Project Review Panels
  5. Thou Shalt Not Provoke Burnout
  6. Thou Shalt Seek Outside Assistance as Needed
  7. Thou Shalt Empower Project Teams
  8. Thou Shalt Use Project Management Tools
  9. Thou Shalt Reward Success
  10. Thou Shalt Not Tolerate Quick-and-Dirty Work Efforts
 Robin Hornby, in “A brief guide to the art of righteous project management” suggests the following:
  1.  Thou Shalt Speak Thy Truth
  2.  Though Shalt Not Say ‘Yes’ in Haste
  3.  Thou Shalt Lead Thy Sponsor Down the Path of Reality
  4.  Thou Shalt Not Present a Single Point Estimate
  5.  Thou Shalt Pay for Quality, Just as Surely as Thou Payest for Thy Errors
  6.  Though Shalt Not Avoid Conflict
  7.  Thou Shalt Put Thy Stake in the Sand
  8.  Thou Shalt Not Plan The Unknowable
  9.  Thou Shalt Rid thyself of Incompetence
  10.  Thou Shalt Not Assume That Which is False
Edward Yourdon, citing the above ComputerWorld list, suggests the following in his Yourdon Report:
  1. Don’t fail to identify the key “players” who will ultimately declare “success” or “failure” for your project
  2. Don’t fail to clearly identify (preferably in writing!) what constitutes “success” for your project
  3. Don’t confuse “estimating” project schedules and budgets with “guessing” or “negotiating”
  4. Don’t ignore the non-linear nature of tradeoffs between people, time, money, and quality when negotiating key project parameters
  5. Don’t attempt to “freeze” user requirements; do expect “scope creep,” but don’t accept “requirements churn”
  6. Don’t allow developers and key end-users to stop communicating with each other
  7. Don’t commit teamicide
  8. Don’t ignore whatever software processes the project team has committed to
  9. Don’t skimp on risk management
  10. Don’t forget the importance of a “daily build” approach
 There are others, but I think I will stop here.
And now, without any further ado (drums in the background….), here’s my humble go at The Ten Commandments of Project Management:
  1. Know your goals
  2. Know your deliverables – Know what DONE looks like and Know how DONE is measured
  3. Know your schedule, cost and technical performance measures
  4. Know your risks and your risk plan
  5. Know your stakeholders
  6. Know your team members
  7. Adapt your communication to the listener
  8. Treat your team members with respect and with dignity
  9. Expect your team members to do their job but don’t demonstrate blind faith
  10. Take it easy – enjoy what you do – or else find another job
Article shared by  @ronrosenhead from quantmleap

Are You a Project Driver or Enabler?

Project managers are tasked with many simultaneous responsibilities. They manage and drive the delivery of a project while managing their team to deliver results according to the business expectations, on time and on budget. It's no small feat when this is accomplished seamlessly.

As a project manager, many times I find myself to be the driver, serving as the catalyst for movement and action.

A driver is someone who takes on the responsibility and accountability for the project deliverables. So, in addition to day-to-day team management, I drive the alignment of the team to the project plan, maintain quality standards with the delivered work and determine the project execution and communication methods.

Enablers act as complements to the driver. They go beyond the task of effectively driving the project activities and focus on the elements that empower the team by fostering a strong work ethic, high morale, satisfaction, and attaining personal and professional accomplishments. Enablers are very good at working with all the team members -- internal and external to the project and organization -- in such a way that allows everyone on the team to:

•    Align to the overall goal

•    Emotionally connect to why the project's overarching goal is important

•    See their own purpose on the team through their contribution and knowledge

•    Feel validated for their inputs and recognized for their efforts and outputs

Enablers add life and color to the project. They are known as the glue that keeps the team together. An enabler can exist within the project team, and he or she doesn't have to be the project manager.

The great value of project managers serving as enablers is that -- when combined with their authority, they are able to drive the project and enable their teams to deliver higher quality projects and longer lasting results. This value is reflected in the quality of the product or service, processes and process adoption rate, plus greater organizational awareness and integration.

Article by Dmitri Ivanenko, PMP for Voices of Project Management

Tuesday, March 20, 2012

Plan Project Requirements Framework

Project requirements are rarely collected and made available in a final form to a project team. Instead, requirements are often collected through an elicitation process, which involves a discovery, analysis, understanding and validation endeavor.

Usually, a business or requirements analyst carries out the requirements elicitation process. The project manager is typically responsible for planning and setting up the requirements elicitation and management framework.

Well-planned and well-managed project requirements are common characteristics of successful projects.

This simplified framework can be a guiding requirements checklist for project managers:

Organizational assets: Identify the available organizational process assets for planning and managing project requirements. The organization or project management office might already have standards, guidelines and templates that can or should be used as a starting point.

Stakeholders: Use the stakeholder register to identify the stakeholders who will help provide, collect, analyze and document the project requirements.

Categories: Identify and categorize the requirements types that are to be elicited, such as:

  • Project requirements: Business requirements, end-user requirements, functional and non-functional requirements, etc.
  • Product requirements: Technical requirements, product features, functional requirements, etc. 
  • Indirect requirements: Overhead imposed by organizational or enterprise environment and standards related to security, regulations, infrastructure and industry, etc.
Channels: Identify the channels through which requirements will come in, such as business-use cases, focus groups, requirements workshops, surveys, product introspection, reverse engineering or  imposed by the organization.

Documentation: Identify how requirements will be documented, whether it's textual form, graphically or using a formal requirements language. Identify the way requirements will be tracked -- through requirement tools, Word documents or spreadsheets.

Maturity Index: Establish the criteria by which requirements are validated and qualified. Is it clear? Does it make sense? Is the criteria aligned to the project vision and goals?

Prioritization: Identify the criteria on how requirements will be prioritized and scoped. For instance, list the must-haves first. Then come the "quick wins," requirements based on the owner prioritization, complexity and costs, the project phase, etc.

Risks: One of the main inputs for the project risk management plan are the scoped requirements. Identify the requirements posing a risk to the project. Develop risk mitigation, response and tracking plans.

Change management: Establish the criteria for detecting scope creep and basic rules for handling requirements changes for applying the change management process.

Article by: Marian Haus, PMP for Voices on Project Management

Wednesday, March 7, 2012

What The Hell Is Project Management, Anyway?

I thoroughly enjoyed this article written by Kevin Purdy for Fast Company. Hope you do to too!

"Project management" can sound like everything and nothing all at once. We spoke with a project management pro to clarify what it really means to get people moving in the same direction.

Project management seems like a classic chicken-and-egg career conundrum: How do you prove you’re adept at managing projects if you haven’t worked as a project manager? Beyond that, what does project management really entail, and how is it different from, you know, being a manager? And what tools do the pros actually use, since there seem to be a new one released every week?

To better understand some of the managerial speak around project management, I spoke with a 20-year veteran of the field, Frank Ryle. He’s worked as an international project manager for Arup International, managed construction and operation of the first Cadbury Schweppes factory in Russia, and now trains and teaches project management. Ryle analogizes project management to a nine-hole golf metaphor in his book, Keeping Score: Project Management for the Pros, available now as an ebook and due out soon in paperback.

In a phone interview, Ryle was, well, frank, honest, and eager to clear the clouds of vagary away from a field he’s worked in for most of his adult life.

Fast Company: Where did project managers come from? Have they always been around, just under a different name? Were they just good bosses?

Frank Ryle: Project management was just a thing you did, a job you had, but nobody wrote about it just a little while ago. You weren’t a ‘Project Manager’ in the 80’s and 90’s, but when something went good or bad, everybody else stepped backwards, and you were the one left. Project managers were the only ones who could talk about the process, not just the product. And, usually, you were the person who had the charm to do it.

Where do project managers traditionally turn to for education and improvement?

We all mostly learned by doing it. But after a while, it was the PMI (Project Management Institute), and particularly the PMBOK (Project Management Body of Knowledge). That’s a big book, and written for insiders. What’s that saying--once you put it down, you can never pick it up again? Since the first version, in the late 1990’s, it’s grown to about 37 official steps. It’s the de-facto bible.
My book is a simplification of that. One way of putting it is, if David Allen is about Getting Things Done, this book, and project management generally, are about getting bigger things done.

Let’s say you want to get project management experience, but you can’t really get that kind of leadership chance at work. What’s a good way to start expanding your skills on your own, maybe in spare time?

Everybody has projects now. Lots of people have projects in their work, they just don’t know it. Software has automated a lot of things, but not goals, resources, and products. That’s something you can find in all kinds of work.

What kind of person makes a good project manager?
You should be comfortable with ambiguity. You have to be willing to reshape the rule, the process, whenever things change. It’s really important to be comfortable with people too, different cultures, so much of business being international now. You’ll be called to walk into a situation where you don’t know the people you’re working with, maybe not even where, or their genders, and say, ‘How do I work with these people?’ You’ll have to create a bit of a roadmap for yourself, and, hopefully, be likeable enough to get by.

There are lots of tools out there, but it seems hard to know if one works until you’ve run through a project. How can someone make a good choice?

Use a tool if it suits you. And it’s a natural impulse, really. I’ve seen people set up big company-wide Microsoft Project installations, only to use it just to create simple Gantt charts. Don’t rush out and buy a Swiss Army Knife. If you hire a carpenter and they come to your home, you can ask them if they use a Swiss Army Knife, and they’d laugh at you. They’d have a good hammer, a good saw, a screwdriver. Some of our gadgets and software try to do too much. But some tools are great, and they’re getting better. We have, I’d say, another five years before we see the light with our software.

What do you mean by that?

There are people who get lost in projects, but we never know. People will ask them, ‘How’s this project going?’, and the response is, ‘I’m fine, but what have you heard?’ We need tools that are like a GPS in a car--they take information from three or four satellites, or, in this case, multiple clues. Software that’s aware of everything--the weather outside, price estimates, maybe even politics, in international situations.

So technology isn’t something that’s made project management necessarily easier, overall?

I think technology has given us a wonderful communications tool. But it’s made us more efficient, not more effective. There’s a difference: Remote working has put us in a position of having to impress our bosses, giving constant feedback, which is not what every project manager wants. The point of getting somebody to do something is to get it done, not to have them impress you.
When you wanted to get a team working on something back when, you’d get them together in a room, they’d pass bits of paper around, and they’d get it done. Once software actually gets us to that condition again, then we’re effective.

What’s one of the best tips you’d give someone managing their own projects, maybe in their off-work hours?

In project management, too many people don’t create a WBS, a work breakdown structure. They have a schedule, and they have a budget, and neither are accurate. You create a document that’s just the work, with names, the amount of work, estimates on the time for the work.
You’ll hear (as a project manager) people say that, if they had known all the work that would be involved in every step--deliveries, committees, approvals--their estimates would have been better. The WBS will make you better.

Follow on Twitter: @KevinPurdy, and @FastCompany 

Saturday, February 25, 2012

Project Management - Is Education More Valuable Than Experience?

In my more than 20 years of experience managing technical projects, most project managers move directly from engineering into project management - do not pass go, do not collect $200. Does this count as the experience necessary to manage a complex technical or non-technical project? Does his or her ranking as a subject matter expert qualify her for the position of manager? Are the skills necessary for each so different? It’s often been said that the best way to lose both a good engineer and a good manager is to move the engineer into management.

Far too many projects fail to achieve their purpose, or scope, within the established schedule and budget. If we assume that the schedule and budget are achievable and reasonable, then what causes these projects to fail? The possible causes are too numerous to list and each project would require a root cause analysis, but every “tiger team review” that I’ve attended have determined that the seeds of failure were planted in the early stages of the project, especially during the initiation and planning phases. So, what roles do education and experience play in preventing these project failures?

Starting with education, managing a project is much like managing a small or medium sized business with the exception that a project is time limited, whereas a business is expected to continue operating indefinitely. I use “business” rather than “department” because a department is most often organizationally and functionally limited, as opposed to a project that has elements of management, human resources, engineering, manufacturing, marketing, sales, and even government relations responsibilities. There are also a number of specialized processes associated with a project, each of which includes a set of specialized tasks. These high level processes are initiating, planning, executing, controlling and closing. Addressing just the initiating process, the project manager has to consider the initiator or sponsor of the project; the contract, if it’s an external project; the scope, or the final deliverables expected; organizational culture; project management tools available; standards, guidelines, defined processes; human resources availability; historical assets and lessons learned from previous similar projects. She must also identify all stakeholders, both positively and negatively affected individuals and organizations, to the project. Her experience as an engineer or subject matter expert is of minimal benefit as a manager of a project, but experience as an assistant project manager is of immeasurable value. Also, education in the form of an MBA or business degree, backed up by certification as a Project Management Professional (PMP®) from the Project Management Institute, provides an excellent background for the new project manager.

The question of whether experience or education is more important to the success of a project manager is that both education and experience are essential, but the experience must be in the field of project management as opposed to the field of the subject matter expert. Project management experience at some point will trump formal education, but that point is after many years of managing complex projects.

About the author:
Owen Murphy has more than 20 years experience managing successful projects in Europe and Asia as well as domestic projects in the USA. He has both the education and the experience to manage projects of all sizes. He holds the PMP certification as well as the Certified Management Consultant certification from the Institute of Management Consultants. See

Rediscover Project Management Knowledge

Do you ever notice how after learning a concept many years ago, when you come across it again, you understand it either differently or better?

As we experience "life" in project management -- managing various projects, working with new teams and wearing different hats on those teams -- we get to see various aspects of project management in action. We add to that knowledge from our own successes and failures.

We usually refer to those experiences as growth and development. The experience alters how we see things and how we communicate with people: our teammates, suppliers, third party partners, customers and clients. It also alters how we perform work because we gain a new point of view or change in our current point of view.

As such, it's valuable to review what you already know by reading through chapters of A Guide to Project Management Body of Knowledge (PMBOK® Guide) to focus on the key areas that you work in, be it in risk management, scope management or resource scheduling.

When you review the material after having had some experience, you not only remind yourself of what you learned initially, but you see it differently. You catch some elements that you didn't see how to implement before, or you recognize how to relate to something in a way that you didn't before. Having that "life" experience in project management alters how you see the material and how you apply it in everyday work.

This happened to me when I reviewed the PMBOK® Guide recently. After reviewing the chapter on risk management, I realized that my company needed to include additional steps for how we handle a backup or restore operation. While many companies have testing strategies, ours only documented this step conceptually. I may not have noticed this if I hadn't reread the PMBOK® Guide.

I challenge you to review the knowledge in the PMBOK® Guide and see how you can apply it to your active projects. Areas that you can improve on will turn up and will add value to your project management practice.

How do you rediscover your project management knowledge? Have you rediscovered practices from the PMBOK® Guide recently?

Article by Dmitri Ivanenko, PMP, for Voices on Project Management.

Thursday, February 23, 2012

The Silent Generation on Project Teams

As projects teams have become more dispersed around the world during the last two decades, the multigenerational project team inadvertently came into existence. Since then, I've dealt with diversity, virtual teams and multicultural issues.

As a project manager of multigenerational teams, my main objective is to figure out how to reconcile generational differences. These differences occur in everything from values and characteristics to priorities and motivation to feelings toward technology and management styles.

In order to more effectively manage multigenerational project teams, I not only need to focus on a team member's visible characteristic actions and behaviors, I have to find out more about his or her generation's beliefs and attitudes. From here, I can tailor my management style.

Take the Silent Generation, for example. Members of this generation were born pre-World War II. In the United States, this generation grew up in a time of economic turmoil and world conflicts. They set their values on discipline, respect and self-sacrifice.

For me, it's very important to understand that discipline, loyalty and working within the system are among the values that members of the Silent Generation will bring to my project team. I have to appreciate that those members have a vast knowledge to share and high standards on work ethic.

In communicating with members of the Silent Generation, I've found that face-to-face meetings are more effective than using e-mail or conference calls when discussing project matters.

Team members who belong to the Silent Generation have a clear understanding of authority, regardless of how old the project managers they work for are. This, along with respect for authority, was prevalent in their early years as they grew up in homes where the mother typically stayed at home and the father went to work.

Members of the Silent Generation bring experience and balance to the project team environment. Their views are based more on common sense than on technology -- as is the case with some in younger generations.

Article by Conrado Morlan, PMP, PgMP for Voices on Project Management.

Steve Jobs Was a Great Project Manager

Steve Jobs Was a Great Project Manager

Now let’s look at Apple – take 2. When Jobs came back to Apple in 1997, some important traits had changed for the better. And some had been good all along.


In general, Jobs was a decisive leader. There are examples when he wasn’t sure which direction to go in, but for the most part he always had a strong feeling about a particular direction he wanted the company to go.

When he made up his mind, that was all she wrote in most cases. Even better, in these years he showed signs of actually changing his mind. With the Apple stores he had been set to organize them by product, and Ron Johnson told him they should be organized around the different types of uses instead.. 6 months after he had been working on iterating a prototype store, all organized around products. Jobs was irate and going into a meeting told Johnson to shut his mouth and not mention it to anyone. Then in the meeting he surprised Ron by saying “Ron thinks we’ve got it all wrong. He thinks it should be organized not around products, but around what people do. And you know, he’s right.”

He didn’t waffle, he changed his mind decisively and immediately set the team out to execute on it. You’ll also notice Jobs giving more credit to people other than himself like this, starting in the late 90′s with his return to Apple. I like it.

Visionary and Charismatic

These traits are impossible for anyone to deny Jobs, throughout his career. He was able to imagine a radical new future state over and over. Even more important, he had the charisma and salesmanship to convince everyone else to follow his vision.

As project managers the better we are at this, the more effective we’ll be in leading our teams to success.


A common thread you’ll notice throughout Jobs’ career is focus, almost to a fault. Sometimes this resulted in micro-management on tiny aspects of a product most people consider trivial and unimportant. But every detail was important to Jobs.

His product launches were a result of meticulous attention to detail, ensuring everything was just right. Apple products were and are the same, setting the company and not just it’s products, but the ‘Apple Experience’ apart from the rest.

Collaborative, Integrated Process

Jobs looked at products as something to be developed in an integrated fashion. After he came back to Apple, he tried to eliminate the ‘throw it over the wall’ and ‘that other department’ mentality by including all groups in discussions around new products.

He also ensured that key new hires met with key players from all departments, not just those they would be working in. This further ensured new employees had a sense for the whole and not just their own little silo in the company.

Most of all, he understood that the full value stream of a product is what matters, not individual steps. From designing the optimal customer experience at Apple stores and the packaging of all Apple products to the inclusion of marketing, sales, manufacturing, hardware and software development people in every step of the product life cycle — he saw the importance of that full value stream.

See other related posts by Josh at:

Friday, February 17, 2012

5 Ways to Find the Perfect Candidate through Social Media

Many people have psychologically separated social networking sites such as, LinkedIn is for business, Facebook is for home, and Twitter is for Gen Y.

What people don't realize is that the separations of these sites are becoming blurred because hiring managers are looking at the entire candidate, and not just what's on a resume.

Here's a trend I'm seeing that can help hiring managers (and maybe jobseekers) to find the prefect candidates through social media.

1. Having a Profile Picture: One of the biggest mistakes people make is not having a professional profile picture on their social networking accounts. Most would argue, "why is that necessary when it's the experiences that matter?" Although that may be true, we are visual beings and unconsciously relate more to visuals than non-visuals.

2. 500+ Connections on LinkedIn: Having that amount of connections dilutes the purpose of a professional networking account like LinkedIn. It gives off the signal that you will connect with anyone that wants to connect with you. Many hiring manager use LinkedIn to find potential candidates and have a red flag when they see more connections than the person can possibly know.

3. Facebook FanPage: With unemployment still high in the U.S., more and more people are coming up with creative ways to professionally stand out. People have created very well thought out and nicely designed Facebook Fan Pages as marketing material to help sell their skillsets. If you do a search on Facebook, you'll find great examples of Fan Pages.

4. #HireFriday Twitter Thread: I came across Margo Rose, an HR consultant, about a year ago on twitter. She had organized a twitter thread called #HireFriday where jobseekers post their skillsets and recruiters or others would actively make introductions to hiring managers with open positions. It's grown from it's inception and you can find out more on her blog

5. Online Resumes on This site is slowly becoming a popular way to point people to an online profile that consolidates all your social networking sites. It's meant to brand all perspectives of a person into one place. It's mainly used as a virtual business card and in some cases, resumes.

About the author:

Bernardo Tirado is an industrial psychologist and project management executive with extensive experience in building global shared services and developing new business capabilities.