In Agile project management, we must prioritize a requirements list for release planning, iteration planning and the insertion of new requirements. But there are several techniques to do this.

One of the most popular methods of prioritizing Agile project requirements is the "MoSCoW" approach. This stands for 'Must, Should, Could, Won't.' The only problem with this method is that everything is usually a must -- which doesn't allow proper Agile release planning because the requirements aren't necessarily put in order of priority.

Another method is the Kano model, developed by Professor Noriaki Kano, which strives to fulfill requirements and please customers. This model features four components:

•    Must haves are elements the product cannot ship without.
•    Dissatisfiers are things the product must NOT include.
•    Satisfiers include requirements where the more you have the better the product is perceived. Like a marketing checklist, each feature adds incremental value.
•    Delighters take the product beyond simply meeting the requirements to boosting customer satisfaction and recommendation.

Several prioritization models put together a table weighted by two variables: features and customers. Each feature is weighted by its value to each customer. The sum of the weights multiplied by the scores makes it possible to see which features are most useful overall across the set of demanding customers.  

No matter which technique is used, your list of project requirements must be sorted from most to least valuable.

What techniques do you use to prioritize requirements?

My project team and I had embarked on a massive renovation to our company's main movie theater. It was one of the largest projects we'd done to date. And it was one of those "your job is on the line if something goes wrong" type of projects.

Such a big project brings some very big potential risks. My project delivery team and I made a list of possible risks plus a list of planned responses. Should one of the risks actually manifest, we knew exactly what to do.

As you may have guessed by now, this huge project that couldn't go wrong went very, very wrong.

Our team realized one thing while planning: We know that we don't know. Irritating as that phrase is, it may keep you from ruining what would be an otherwise successful project.

We knew that even our collective genius may not be enough to avoid disaster. But rather than spend the time creating mitigation plans for unpredictable risks, we created a mitigation plan for the actual risk of not knowing what could happen.

The plan included an eight-step process tailored to how the project team operates and how we run our projects. This gave us a standard procedure to follow if trouble arose. And when it did, we used that mitigation plan. There was no need to worry. Everything was under control, even for a risk we hadn't specifically planned for.

Because of this project, my team and I still always assume an "unplanned for" risk is on the horizon. We always give our due diligence to risk management and create responses for risks we can specifically identify. But then we review our eight-step plan to ensure we're all prepared for the unknown.

Do you have a risk-management response-mitigation plan in place for risks you know you don't know? 

Elements of the project are falling apart, whether with the team, with the supplier or in your project management domain. Now is the time to regroup, reengage and reset everyone back in the direction of the project goal -- before it's too late.

To regroup, conduct a structured session with the core project team to capture the status of everyone's tasks. The regroup can be in the form of a meeting, brainstorming session or workshop. This way, no one on the team is invalidated for elements that went wrong, and you can show your appreciation for everyone's input. Allow for a discussion of their concerns.

To reengage, work with the team to align with the original goal, requirements and project deliverables.

Then, reset the expectations of each team member, as well as your responsibilities as the project manager. Finally, implement any changes required for the successful delivery of the project.

Separate failure to perform from a lack of teamwork within the group. This action allows you to focus on how to achieve the expected results of the project, with buy-in from the entire team.

What do you when your projects are off track?

Web 2.0 is changing the way stakeholders interact and work together within the project team and in the wider community around the project and the organization. Social networking, instant messaging and collaboration tools are overwhelming traditional organization charts, hierarchies and management structures.

Here are a few examples of how things might change:

Building and maintaining relationships will change. People add their uniquely human value in non-routine processes and creativity and organizations will increasingly use automation or "self-service" systems for the majority of routine activities. There will need to be a balance between pure efficiency (which is often appreciated) and developing meaningful relationships with stakeholders through human interaction.

Weak links and extended networks let people pick up information from people who know the people they know. Project managers will need to learn to navigate their personal, professional and social networks to exploit these strong and weak links for the benefit of their project.

Work swarming is characterized by a flurry of collective activity by anyone available and able to add value. Using weak links, swarms form quickly, attack a problem or opportunity, and then dissipate. The phenomenon is powerful but not controllable in any traditional sense.

Informal groups outside the direct control of the organization often use social media to impact the success or failure of a project. Smart project managers will learn how to live in a social environment they can only partially influence.

Virtual environments will become the workplace. People will interact with each other and the virtual environment to reshape the world they're looking at through simulation and experimentation.

The challenge facing organizations and project managers is adapting to this environment to obtain the potential benefits for the project, the team and the organization. They must simultaneously maintain appropriate levels of governance and remain focused on the project objectives.

Individuals will also need support to manage the complexity created by overlapping demands. Forcing individuals to operate in an over-stimulated state will be detrimental to the person and their performance on the project team.

How is Web 2.0 affecting your stakeholder management?

I have a feeling the nature of project management -- which has sustained my career for more than 20 years -- is changing radically.

Two tectonic shifts in the business world made project management an obvious career choice for me back in the late 1980s:

1. Just as I was about to enter middle management, 25 percent of such jobs were eliminated from the economy.

2. Around that same time, organizations began to reorient their thinking and started to define and organize themselves as project-based businesses.

Explicitly in response to these two phenomena, I consciously made the decision to leave line management and enter project management. The writing on the wall is certainly clear in retrospect. And honestly, it was pretty clear at the time as well.

Now, I see three things happening that give me pause. They're clearly things I need to react to, but unlike last time, I don't know how.

1. Lower-level IT jobs continue to go to emerging markets. As the people who took these jobs 10 years ago mature in their roles, more of them are becoming project managers. They're close to their teams and to the work -- even if the sponsors are elsewhere.

2. The way project work gets done, particularly in the IT industry, seems to be undergoing an important shift. I really don't know what's underneath it, but I do know that PMI has embraced Agile development, even offering an Agile certification. Is this the direction in which IT is headed?

3. As we emerge from the economic crisis, every indication is that the way the global economy will function in the future will be very different. We keep hearing of a "new normal."

To me, these three things spell change, and it seems to me I ought to be making some changes as well, but I'm not sure what they are yet.

I'd be interested to hear and learn from you. What are your observations? What are your plans?

Editor's note: In Project Management Circa 2025, published in 2009, editors David I. Cleland, PhD, PMI Fellow, Bopaya Bidanda, PhD, and 39 experts from around the world share their insights on the future of the project management profession.

Scheduling time to execute your work is one thing. But project managers should also schedule time for scheduling.

Setting aside a block of time each week lets you review your project plan, timelines and pre-requisites. It also lets you gauge whether you're still on track with deliverables and if you must make any necessary tweaks to your plan. I review all of the planned activities at least a week out and make sure everything is aligned to execute those activities.

I recommend creating a two-month view of the project, no matter what the size. With that in place, it's a matter of confirming that you're still on target.

At the end of each day, schedule an additional 15 to 20 minutes to look at the next day's schedule. I make sure all the meetings and activities that my team is managing are well-planned, scheduled and confirmed.

It may seem tedious but spending time on scheduling will help ensure you stay on top of your plan and know that it's on track.

Do you schedule time for your planning? Is it worth it?

In my previous post about whether crowdsourcing was worthy of all the exposure and hype, I asked for people's opinions.

Well, you certainly responded, not only in comments on the blog but also through emails and on Twitter. Your responses were very helpful and well-thought-out.

After reading your feedback and doing some research, I came to the conclusion that crowdsourcing can be a very effective tool. But only if it's used for a well-defined, focused portion of a project. 

Crowdsourcing generally works best when you need a sampling of input from a large population. This can include activities such as requirements gathering, securing non-rights-protected content or a resource donation (such as computer bandwidth). Some mentioned software testing as a crowdsourcing activity. In this case, it's no different than what companies have always done when their products go "alpha" and "beta." People are simply slapping a new label on an old activity.

In any crowdsourcing scenario, the activities must be considered voluntary. There must be no compensation or contracts. And project participants must have a clear understanding that any contributions - tangible or intangible - are the property of the entity soliciting the input.

My rule regarding compensation for work could potentially be broken through a contest approach such as the Netflix Prize project, which focused on algorithms to enhance the company's ratings system. But activities like these would have to be tightly managed.

Are you or your company evaluating whether or not to foray into crowdsourcing? What types of projects will you use the activity for?

Agile teams often rely on burn-down charts to show how much work remains in each two-week sprint. The starting point represents the total work to be done and ends at zero when it's finished. There's no detailed plan of how much work is done each day -- teams just draw a line from start to finish.
 
But two problems can arise:

1. Teams get used to collecting data, but forget to interpret and take action on it.
 
2. Executives may look at the graph and become concerned if the actual numbers don't track precisely to the projected line.

So how do you know when to be concerned versus when the numbers are varying normally? An average of 20 percent variance is a good rule of thumb. Anything less is a false alarm. Anything more demands attention.

Here are some models I've created of possible scenarios, but in reality, progress is more of a wandering curve. The vertical axis shows how many hours are left and the horizontal axis shows how many days are left. The straight blue line represents the planned amount of work left each day in hours, while the red line shows the actual hours left.

Case 1: Under the line
The team consistently finished more work than expected. Does this represent an error in estimation or natural variance in the system?


 

Whether I'm the project manager or a team member, I am completely in control of the way in which I interact with people on my team.

I regard my team members as powerful individuals, regardless of their knowledge, experience or personality. With this as the context for my interactions, they can achieve results, complete work on time, support their teammates and share their knowledge.

To foster this kind of environment, I ground myself in the project goal. I determine what's required to achieve results efficiently and with great collaborative effort. Then I translate that to find a way I can help the team by being supportive, open, connected, appreciative, or being someone who consistently celebrates the success of others.

Have you worked with someone closely and over time, and found you could support each other and contribute to each other's work, without doubts, worries or concerns? That's what happens when I create an environment that allows me to be with people that way right from the start.  

How do you elevate your team to the next level of performance?