Voices on Project Management

> Back to Voices Home

July 2012 Archives

Plan for Special Events on Your Project Calendar

| | Comments (0)
The months of July and August have a few events that can put kinks in your project plans in the Gulf Cooperation Council (GCC) countries.

During the summer, for example, temperatures can reach as high as 122 degrees Fahrenheit (50 degrees Celsius).

Project managers working with or in the Muslim world also need to plan for Ramadan, when the majority of the population fasts between sunrise and sunset. Then there's Eid al-Fitr, a national holiday that marks the end of Ramadan. Its importance is similar in scale to Christmas or Yom Kippur.

These combined events mean project managers must plan meticulously to ensure minimum disruption to their project schedules.
 
During this one month, the expected impact on the construction sector alone is a reduction of productivity by 40 to 60 percent. The main causes are heat and a fasting workforce that is unable to work at full capacity.

Additionally, project managers in construction face government constraints, which forbid laborers to work more than six-hour shifts in the day. They must stop working at noon and wait until it gets cooler to start again.

To keep project schedules moving during the very hot weather and major holiday, the key is to plan, plan -- and plan some more. These planning best practices can help:

  1. Begin planning for special events about three months prior. The project manger should meet with the customer, contractors and suppliers to agree on expectations, tasks and deadlines.
  2. Determine activities that can be moved up or delayed to compensate for risks during the special event, such as climate, absent staff and lower productivity.
  3.  Employ more staff to compensate for loss of productivity. 
  4. Keep a sharp eye on daily logs. Doing so will minimize risk -- especially in cases where work hours or the calendar have been altered and extra resources have been employed.
  5. Communicate with teams on when they expect to complete tasks. Coordinate dates and lines of escalation in the absence of managers.
  6. Ensure health and safety of employees in the work place. In the case of heat, plan for generators to cool work sites, for example. Provide plenty of water, appropriate clothing and equipment.
How do you plan for special events in your project calendar?
 

The 'Appropriate' Project Approach

| | Comments (9)
I recently attended a two-day workshop to help me get certified as a Scrum master.  What made this class interesting is that I am a "traditionalist" -- a project manager who leads and manages projects using the waterfall approach. This was going to be a whole new ballgame for me.

While I am not particularly new to the concepts of agile, I was looking forward to learning the extended basic agile concepts, frameworks and skill sets, and learning to apply those skills.

Surprisingly, I understood more of Scrum than I thought I would and realized I was already implementing some agile principles into my waterfall projects. Most importantly, I realized that the debates surrounding waterfall versus Scrum may just be full of hot air.  

The focus of those arguments is that one approach is categorically better than the other in all circumstances. That couldn't be farther from the truth. Traditional and agile frameworks are neither better nor worse than the other. But, either could be completely disastrous for a project if applied broadly.  

One of the most important ideas I took away was the idea of 'appropriateness.' Scrum is about finding the right level of planning, documentation, velocity of task output, cost and schedule -- and not just per project, but per team. It's not about what is 'best,' but what is appropriate and suitably fits the set of circumstances at hand.

I began to think that if all project managers embraced this idea of using an appropriate approach instead of the perceived 'best' approach, projects could potentially get along much better than they currently are.

I think that what is appropriate for a project could be waterfall, it could be agile or it could be a hybrid. And that would mean project managers would have to be well versed in all kinds of approaches and understand several project management languages.

At the end of the two days, and after an online assessment, I became certified as a Scrum master, but I think I became more than that. I got better at being able to identify what a project needs and what a team needs. Now, I have a few choices as to which approach is appropriate to meet those needs and ensure success.

Do you think there can be a hybrid?

PMI held the 2012 PMI® Research and Education Conference 15 July - 18 July 2012. The conference, which was held at the University of Limerick in Limerick, Ireland, brought together more than 260 researchers, academics, students and practitioners from 35 countries.

This was my first research conference, so I really wasn't sure what to expect. I was completely overwhelmed by the continuous interaction and knowledge sharing between researchers and practitioners.

PMI Board of Directors Chair Peter Monkhouse, PMP, set the tone for the conference during the opening session when he told researchers that the work they are doing is helping practitioners to be able to do projects better so that their organizations can meet strategic and business goals and be successful.

The 2012 conference was full of valuable content and featured something for everyone: a special symposium on the alignment of academic research with the needs of the practice community; discussion sessions on topics such as PMOs, program management and complexity; and interactive incubator sessions where attendees could discuss and respond to research in progress.

The conference featured three distinguished plenary speakers: Raymond Levitt, PhD, Director of the Collaboratory on Global Projects at Stanford University; Denise Rousseau, PhD, University Professor at Heinz College and Tepper School of Business at Carnegie Mellon University; and Christopher Loch, PhD, Director, Judge Business School at Cambridge University.

Several pre-conference sessions were held:

  • Doctoral candidates were able to present their research to an audience of peers and international scholars at a doctoral colloquium. A total of 13 students presented and gained feedback on their research.
  • A Global Accreditation Center (GAC) Academic Forum, which nearly 30 participants representing 15 universities in 10 countries attended. 
The morning session focused on GAC accreditation, with a session on the GAC accreditation process and presentations from universities who have GAC accredited programs. An interactive discussion followed the presentations, where the program representatives, GAC board and staff discussed all aspects of the GAC accreditation program and process with the audience.

The afternoon working session presented an Oxford Debate on the Flipped Classroom Concept with a motion of "Flipped Classrooms and experimenting with teaching is the way forward for project management education."
 

  • Nearly 40 scholars participated in a case writing workshop titled "Leveraging Your Research into Teaching Cases."
The workshop, which was led by Mark Jenkins, Director of Research and Professor of Business Strategy, Cranfield School of Management, provided attendees with tools to use their empirical research findings or publicly available information as the basis for writing a teaching case.

One of the highlights for me was the recognition of this year's award winners, which recognized scholars, senior practitioners and students of project management who have produced particularly notable bodies of work in research and education. You can find information about the awards and the winners on pmi.org.

My attendance at this year's PMI® Research and Education Conference was definitely a learning experience for me, as I strive to learn more about how academics and practitioners can join together to help shape the future of the project management profession.

PMI members can see full coverage of the 2012 PMI® Research and Education Conference in the September issue of PMI Today.

If you attended, what was your favorite session or experience? What would you like to see at the next research and education conference?

A Different Mindset: From Project To Program Manager

| | Comments (3)
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.   

What have you found effective to make the mental leap from project manager to program manager?

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



See more on the Pulse of the Profession.

Stick to Project Management Basics

| | Comments (12)
The importance of fundamentals in project management is obvious, but easy to lose sight of.

As professionals who constantly strive to improve, we study, read, take courses, attend seminars, listen to podcasts and more -- all to become better project managers. Ironically, sometimes this desire to learn causes us to lose focus on the fundamentals.

Instead, we look to novelty, the latest trends and perhaps even the latest fads in the interest of improving.

Likewise, we might embrace sophisticated techniques without ensuring that we've properly implemented the basic things on which the sophisticated techniques depend.

I've often heard great sports figures and musicians emphasize the importance of fundamentals in their success. Project managers would do well to place similar emphasis on the basics of our profession. I'd go even further to suggest that before we embrace any new or sophisticated technique, we should first look at how well we are implementing the fundamentals.

For example, what good does it do us to implement the latest agile techniques on a project where we haven't adequately implemented rudimentary change management disciplines? Similarly, what good would it do to implement Monte Carlo simulations in a context where we haven't adequately identified basic risks?

In my estimation, our success depends almost entirely on how well we have implemented fundamental risk and change management processes.

Things go wrong and plans change -- yet we often charge ahead without adequately planning and preparing for those realities. Certainly, our intuition tells us this is true, and our experience validates our intuition. Yet it still often happens that we lose sight of the obvious fact that the basics matter and matter most.

If you should ever waiver in your conviction, look no further than PMI's 2012 Pulse of the Profession. The report notes that change management and project management basics are among the most critical project success factors.

New and sophisticated techniques have their place, but the best thing to do in any profession is to go back to basics. Don't let the allure of the sophisticated or the novel, distract us from the value of fundamentals.

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



See more on the Pulse of the Profession.

Understand Your Place on the Project Team

| | Comments (6)
Have you ever been at a meeting where someone tries to tell you what you should be doing and how? Even though you are the project manager -- the one who guides the team and makes decisions -- you still have people offering their two cents. The advice can come from a project team member or a credentialed project manager on a different project.  

I have actually done this myself as a project team member. As someone technical, and who also has project management experience and knowledge, I have tried to impart that wisdom to my project manager.

I clearly remember one project manager I would advise on a number of things. It's in my nature that when there's a gap -- whether in communication, documentation, project planning -- I want to point it out.

The dilemma is that if you impart your knowledge too forcefully, you are possibly invalidating the project manager.

In certain situations, that advice becomes unmanageable and puts more pressure on the project manager, not only to manage the project but also to manage you.

If we feel there's a need to bring something to the table that is going to add value to the project, it needs to be brought up as such. You should not expect that the project manager would just implement it because you said so.

Before you even do that, consider asking yourself why you are thinking a particular way about a situation. Why are you asking for the changes? How does it resolve a specific issue that you are dealing with?

Challenge yourself. See if you can adapt and work with your team, deliver what you are required to deliver and, as appropriate, bring up the items that you feel can add value to the project. Understand the value of your place in the project and fulfill on the expectations others have of you.

How do you handle project team members who forcefully suggest their ideas?

Group Creativity Techniques to Collect Requirements

| | Comments (2)
In my previous post, I discussed gathering requirements through a facilitated requirements workshop, conducted as part of the scoping phase.

A few creative group techniques allow a project manager to get the most out of a requirements workshop. They include mind mapping, brainstorming, affinity diagram, nominal group technique and Delphi technique. (A Guide to the Project Management Body of Knowledge (PMBOK® Guide) Chapter 5.1.)

The rigor, the number of applied techniques and the sequence in which these techniques are applied depend on the project's complexity, the workshop audience and the available time for gathering and prioritizing requirements.

Nevertheless, the following approach can be constructive and fruitful for collecting project requirements in a facilitated workshop:

1. Start gathering requirements by using the mind mapping technique.
Start with a topic, an issue or an area that you want to collect requirements for and develop ideas around it. Group the ideas visually, as a mind map, by writing down each idea and drawing how it relates to the initial topic. Ideally, you let anyone in the workshop create his or her own mind map.

2. Continue the process with a brainstorming session.
Allow anyone in the workshop to generate an unstructured requirements list for each idea captured on the mind map. To ensure that the brainstorming remains focused on the initial topic, lay basic ground rules and let anyone freely generate fresh ideas and requirements on the topic.

3. Use the list of unstructured ideas and requirements to build an affinity diagram, where your ideas are organized into groups based on their natural relationship. Let anyone in the workshop participate in organizing the items in the most natural group they can.

4. Identify the most important requirements by applying the nominal group technique. Allow each member or group in the workshop to identify which requirements are the most important for him or her. Rank each requirement on the affinity diagram with a priority: low, medium, high or from one to five. To avoid conflicts, facilitate an anonymous priority appraisal and ranking. Finally, tally the results and identify the most important requirements.

5. Close the process by running several rounds of independent feedback through the Delphi technique. Let any individual or group revise the list of requirements. Share an anonymous outcome from each review round and continue with further rounds, keeping in mind the objective to reach consensus and convergence.

Which of the group techniques are you using for collecting requirements? How do you apply them on your projects?

PMI Members: Learn more about mind mapping in our Knowledge Center.

Project Skills Improvement Through Formal Plans

| | Comments (0)

It is very likely that you have some members on your project team who are more talented or experienced than others. As project managers, we tend to utilize their skills as much as possible because we know that more often than not, they will be able to produce excellent results and meet expectations. 

Nevertheless, this group of people still needs the opportunity to improve their skills and knowledge. This is especially true when an organization needs to stay relevant in the current economic conditions. 

According to PMI's 2012 Pulse of the Profession report, a critical success factor of projects was staffing the team with the appropriately skilled people. Organizations that had a formal process for developing project/program competency saw a 70 percent success rate on projects, versus a 64 percent overall average. 

Unfortunately, Pulse of the Profession also showed that in 2011, only 47 percent of organizations had a formal "talent management" process, down from 52 percent in 2010.

But we must have formal talent management processes to develop project managers and team members, and you must tailor it to the people involved. An effective project manager is only as good as the information that he or she has.

An "accidental project manager," for example, might not have attended formal project management training courses. But fundamental knowledge helps project managers achieve effective and high-quality deliverables. For this group, it would be good to start them off with proper training on the core skills they'll need to grow and succeed as project managers.

Team members who are familiar with project management fundamentals might need help developing in other areas, such as soft skills. Since 90 percent of a project manager's job is communication, maybe you will help them improve in that area. 

Have the team member sign up for a communication course, for example. Choose topics such as influencing skills, which is important in convincing clients and partners. Or, suggest courses on negotiating skills, which is helpful in negotiating a more achievable schedule.

Refresher courses could be helpful for everyone on the team. Look for training that zooms into specific project management areas, such as effective cost and scheduling control, risk management or quality control management. Aim for at least one training session every quarter. 

Do you have a formal talent management system? How do you develop your project managers?

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

See more on the Pulse of the Profession. 

Finding the 'Flaw' in Projects

| | Comments (0)
The next time your boss asks you for a number, a deadline date or another fixed value, remember anything you say will be wrong. The reason is 'the flaw of averages.'

Discussed in a book of the same name by Sam L. Savage, the flaw of averages basically explains why everything is behind schedule, beyond budget and below projection.

For example, you're developing two software modules. Both are expected to take between eight and 12 weeks to complete. When both modules are finished, your organization can start a new process, which requires four additional staff.

Your boss asks you for a completion date so the additional people can be brought 'on-board' and the new profitable line of business started. You say, "Eight to 12 weeks," and your boss replies, "Give me a date!" You estimate that a safe date would be 10 weeks, the average of eight and 12 weeks.

Everyone is happy. But should they be? Let's look at the flaw of the average:

Based on your projected date, your boss works out his profit forecast for the next quarter based on an estimated profit of US$1,000 per week. You take the first seven weeks developing the application, and the new team uses the application for the remaining five weeks.

This sounds sensible, but the estimate of US$5,000 profit is the best that can be achieved. If you finish early, there is no upside. The new people will not be available.

If you finish late, however, sales will be lost. The cost of the unproductive new staff will be an added expense until both modules are working. On average, the profits achieved are likely to be significantly less than US$5,000.

Plus, you're more likely to be late than early. The probability of finishing each of the modules in 10 weeks or less is 50 percent.  It's like tossing a coin - there is always a 50 percent chance of it landing on 'heads.'   

Since two modules need to be finished in 10 weeks or less, think of the options when you toss two coins:

Tails + Tails
Tails + Heads
Heads + Tails
Heads + Heads

There is only a one in four chance of you achieving the 'average.' That 25 percent probability means there is a 75 percent probability of being late. Therefore, on average, you can expect to be late.

All you did was assess a reasonable number based on your expected average time to complete each module. The problem is not your estimate, but the way it is being used. This is the flaw of average.

The next time you are asked for a 'number,' use your skills in managing upward to build flexibility into the conversation.

For example, offer your boss a safe date with an option for improvement. "We will definitely be finished in 12 weeks, and there is a possibility of finishing sooner." Point out the cost risks of being early and late. Keep the boss updated as you work through the project.

Or, do some serious analysis. Offer your boss a range of dates with different levels of probability. You need tools for this, but you want a target date with an 80 percent probability of achieving.

Effective stakeholder management needs more than simply complying with a request -- however reasonable it may appear on the surface.

Project Risks + Proactivity = Success

| | Comments (7)
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.

Do you practice risk management? How does risk management planning make your projects successful?

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

See more on the Pulse of the Profession.

Estimate Time for Agile Estimation

| | Comments (3)
Agile estimates and planning are essential to a project. But a common mistake during rough release estimating is forgetting that the opportunity for a greater level of detail comes later.
 
If that point is missed, teams may struggle during the initial high-level estimates.
 
To avoid that problem, I suggest that at the beginning of a project, teams do a rough estimate of each requirement. One common estimating technique includes "planning poker," also called Wideband Delphi.  



In planning poker, each team member secretly picks a number representing how much effort or complexity they think is involved in a given requirement. The numbers then are revealed. The person with the highest value explains to the team why it is hard. The person with the lowest value explains why it is easy.
 
After no more than two minutes of discussion, the team votes again. This process is repeated until the team reaches a consensus or it discovers there is not enough information to estimate this requirement.
 
The problem arises when teams blur the focus between the low-level estimates for a two-week iteration and high-level estimates for the release. Low-level estimates are more precise because they split a requirement into several tasks, estimated in hours. By contrast, the high-level estimates are in more abstract relative "points."



Some teams incorrectly attempt to identify predecessor dependencies in high-level estimates. They can also spend too long trying to refine the estimate or silo work between sub-teams to make two estimates for the same requirement.
 
This detracts from the goal of being able to estimate a large pile of requirements quickly and at the beginning of your project. Remember, there is plenty of time to deep dive later.

How long does it take you to estimate your project?

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