PM Blog: Kent McDonald

SMART Objectives Aren't Always Project-Specific

2011-12-06T13:37:09-08:00

by Kent McDonald

Project managers for years have measured project success based on three criteria: was it on time, was it within budget, and did it deliver the agreed upon scope? That definition of success is so widespread that the Standish Group has even used that criteria as the basis for its CHAOS Study on Project Management. Unfortunately these criteria are insufficient for measuring project success and can be misleading. Instead of using cost, budget, and scope as measure of success, I use the achievement of business objectives as a true measure of project success.

My friend, co-author, and ProjectConnections contributor Niel Nickolaisen shared the story of a 14-month, $27 million ERP project in Stand Back and Deliver that was on time, on budget, delivered all the agreed upon scope, and was considered a complete failure. The project did not add features that helped the organization build and maintain a sustainable competitive advantage. The team and the sponsors thought that budget, cost, and scope were appropriate measures of success, when really they should have focused on whether what they were doing would help them achieve their business objectives.

Niel would have been well served by having SMART business objectives to refer back to when making decisions on that project. You may be familiar with the SMART acronym. There are a couple of different ways to describe it, depending on what characteristics you want to stress. I prefer this selection of words: Specific, Measurable, Agreed-Upon, Realistic, and Time-Framed.

Specific	Do you have an actual, concrete way of knowing when you have reached your objective and hence were successful?
Measurable	One way to get a concrete way of knowing that you were successful is to have a metric that you can look at it to see progress.
Agreed-Upon	Other people may use different words for the A, but I think this one is the most important. Objectives are not nearly as powerful or useful if all members of the team do not agree that they are important.
Realistic	You are setting yourself up for failure if you set an objective that is impossible to reach. You should stretch a little, but you should not set up an objective that you have no hope of meeting.
Time-Framed	Identify when you are going to reach the objective.

Things that I encourage teams to remember when working with objectives that line up with the SMART acronym:

Identify the metric used to track progress.
Know what the baseline for that metric is—where are you starting from?
Know your target value for that metric—what value do you expect to reach when you are successful?
When are you expecting to reach that target? Consider that you may need to allow some time after the project has been implemented before you can get a useful measure of success.
Do you have a plan for how to get the measure? You'll want to consider this, because it could impact the scope of your project.

Some examples of SMART objectives include (these are, of course, totally contrived):

Increase non-consulting revenues from $0 to $20,000 by December 2012.
Decrease average decision cycle time from five days to two days by June 2012.
Increase Net Promoter score from 45 to 60 by the end of 2012.

The one thing that the SMART acronym doesn't address is the perspective of the objective. Project-specific objectives may be convenient to define but they aren't very meaningful. Meeting a certain cost, time, and scope could easily be seen as project-specific objectives. Projects are generally undertaken to implement some form of change in the business, often implementing some part of the organizational strategy. Since the project is intended to help implement the strategy, the measure of success should be based on how the business is aided. The best way to measure that is to measure how the project contributes to business objectives.

Notice I said contribute. Take another look at the examples I gave above. A project by itself will not enable a small consulting firm to increase non-consulting revenues from zero to $20,000 in over a year. The consulting firm will probably undertake a project to position itself to grow non-consulting revenue, such as creating information products or setting up an affiliate program, but the project by itself will not generate that revenue. Operational efforts will also have to occur, and there may be multiple projects that occur to realize the targeted revenue. Projects often introduce changes which set the company on the path to reaching those objectives, but a lot has to happen in the way of ongoing operations to make that happen.

A different way to do it is to estimate what type of contribution a project will have on the overall business objective and watch to see if that contribution occurs. In some cases you may be able to empirically measure this, in others it may be a yes/no type of measurement: Did the product that the project created contribute to the organization meeting its revenue targets? Measuring objectives in this way may be a little more difficult than measuring whether you met budget, schedule, and scope but they go a long way toward aiding decision making during the project. When trying to make a decision, the project team can point to the objectives they are working toward and ask themselves, "Will what we are planning to do help us meet that objective?"

By focusing on accomplishment of business objectives instead of the points of the iron triangle to measure success, project teams will make more informed decisions about their projects. They'd be more likely to change or stop projects that are not heading in the right direction, and they would focus more on doing the right things instead of doing things right. I know Niel learned his lesson. The ERP project I mentioned above led him to create the Purpose-Based Alignment Model, which is one great way to determine if you are focusing on the right objectives.

Related Links
Niel's Purpose-Based Alignment Model is referenced in Kent's Agile Technique Brief on Project Value Models. Geof Lory has written about improving communication by sharing your goals. A Benefits Realization Plan can help you determine whether or not a project has actually achieved its objectives -- objectively.

Be Careful What You Measure, You Just Might Get It

2011-09-28T16:58:25-07:00

by Kent McDonald

There are two sayings that are commonly used when discussing measurement and management: "You can't manage what you don't measure," and "You get what you measure." It seems that several organizations pay a lot more attention to the first piece of advice without heeding the warnings that come along with the second, especially in the realm of leading project practitioners.

I work a great deal in the business analysis space and have seen this happen quite frequently there, but based on anecdotal information it occurs just as frequently for quality assurance/testers and developers. Basically the leaders of these knowledge workers want to find some way to gauge how well people are performing their jobs. These measurements are then used to determine development opportunities (hopefully) and for the purpose of performance evaluations (more likely). This seems most common in organizations that like to refer to people as "resources" and group them together in teams of similarly skilled people. In other words, all the business analysts are in one group, all of the testers are in another group, and all of the developers are in a third group.

On the surface, this approach makes sense. Everyone with the same skill set is grouped together for purposes of career development and training. The more experienced BA's, for example, can share their experiences with the less experienced BA's, and they can all share good practices. Since their department heads usually used to do the same job, these groups are supported by leaders who understand the ins and outs of their particular skill set. The thinking then goes that grouping people by skill set allows for easier measurement and evaluation, since they can all be measured by the same criteria. That's the idea at least.

But measuring knowledge work can be tricky. Do you measure productivity? (How many use cases can you complete in a week? How many lines of code can you write? How many bugs can you find?) Do you measure based on quality? (How many "errors" did you not put into those use cases, lines of code, or test scripts?) Do you measure based on performance to goals? (I said I was going to write four use cases this week, and by golly, I did.)

All of these approaches certainly provide useful information, but settling on one approach—or even combining metrics from different approaches—applies focus in the wrong place. If a business analyst is measured based on how many use cases they produce, use cases become the end product for that business analyst. If developers are measured based on how many lines of code they produce, the code will become very bloated, and probably not particularly efficient. Testers measured based on how many bugs they find will suddenly detect an infestation that may or may not actually exist.

One organization I recently heard about introduced a new measurement regimen designed to make their business analysts more effective. Their business analysts set weekly goals, and then compare their actual accomplishments with those weekly plans. So far, not too bad; this approach recognizes the need to frequently revisit and revise plans based on the latest information, and encourages the business analysts to do a little forward planning once a week in order to get organized.

A trickier aspect of this measurement program is that the goals that are set are based on how much time is spent doing particular activities, and the work is evaluated as value added or non value added. The value add of a particular task is determined based on whether it is actual business analysis work. So, writing a use case? Value added. Talking to a stakeholder about content for a use case? Value added. Helping another business analyst on another project work through a particularly gnarly analysis problem? Non value added. Helping a tester on their project team write test scripts? Non value added. Attending the team's daily standup? Non value added.

What this and many similar measurement programs seem to miss is that knowledge work is a team sport with the ultimate goal of delighting the organization's customers, not producing requirements, writing lots of code, or finding a lot of bugs. Individual measurement programs encourage sub optimization. Depending on how they are designed, these systems may even actively discourage teamwork. People working under these types of systems will quickly see that in order to get ahead, they can't afford to help anyone else. They have to keep hitting their own individual numbers, because it is not to their personal advantage to collaborate with the other members of the team.

Leading projects in this sort of environment is difficult enough, because as a project lead you typically have to lead through influence. That means bringing people together who report to three or more different leaders, each with different understanding of priority, and with their attention split across multiple projects. Throw a reward structure on top of that which by its very design encourages suboptimal behavior, and now you can't meet your own personal goals, which are usually focused around the legs of the iron triangle. You start making suboptimal decisions yourself trying to work a plan that conflicts with the individual goals of each of the team members. The result is a mind numbing set of discussions where the phrases "that's not my job" or "that's not your job" are heard far more frequently than "how can I help?"

I'm not suggesting you don't measure at all. That would be counterproductive in many other ways. I am suggesting that you change the focus of the measurement from output to outcome. If your organization pulls people together to work as a team, create measurements based on the outcomes of the team's efforts. Did they drive progress toward the business objectives they were seeking to impact? Did they work in an efficient and effective manner? Did they reduce waste in the overall process?

Some people will initially feel uncomfortable with this measurement approach. They may be concerned that they no longer control their fate, that they will be too reliant on team members, and that they will have to carry others' weight. Perhaps, but that will certainly provide some incentive for those team members to help out the ones who may need a little help for the good of the entire team, and for the organization. Placing the focus on the outcome of the entire team will also encourage people to step outside their comfort zone and pitch in on tasks that may not be their direct responsibility, but that they have sufficient skills to perform on a short-term basis. They will become more well rounded and both the people and the organization benefits as a result.

Plus, if you decide to measure based on team outcomes, you might just get them.

Risk Management Takes a Village

2011-07-20T13:31:36-07:00

(Including that IT guy up on Third and Main)

In my current endeavors I have the wonderful opportunity to work with a wide variety of project teams, coaching them on such diverse topics as leadership, collaboration, decision making, and of course risk management. One comment I have heard in every risk management interaction never ceases to surprise me. In my sessions, I discuss the various ways teams can manage risks by considering the approach they use and the decisions they make. Without fail, as soon as we finish these discussions a developer, tester, or business analyst will say something like, "That's great Kent, but I don't see how risk management applies to me."

Seriously?

Maybe the project management community has done such a great job of claiming project risk management as their domain that all other professions have gladly washed their hands of that responsibility. Trouble is, risk management is not very effective if the people in the best position to identify potential risks and affect their impact or probability aren't paying any attention. What's even scarier is that I often hear these comments in financial services and insurance organizations, two industries that make a majority of their income from properly managing risks.

Or perhaps the coverage of risk management has just focused too much on the mechanics and not enough on the underlying premise, leading team members to believe that it's "not their job" to initiate discussion and track project risks. Even if that's true, they are still responsible for getting involved in the discussion. The really interesting thing is that most experienced project team members have all the knowledge and perspective needed to be very effective risk managers, they just don't realize it.

Here's a case in point. Recently I was working on a development project that was introducing configurable data access settings. This meant that any reasonably intelligent administrator (or at least any with the appropriate access rights) could change field-level permissions in the application without changing the code: A feature that is quite powerful, and potentially quite risky. We were discussing whether we needed to create a new role in the application to handle a particular requirement for a group of users to have write access to one specific field. As we considered the options, a developer who had been working with the application for several years spoke the language of risk, without realizing he was doing it.

"Well, we could just assign the people that need to edit this field to this role here, but then they would be able to edit all these other fields, which could be fairly bad. Or, we could take this role here which already has fairly similar rights and just open up that field, which could also have some consequences. I suppose we should just create a new role. That may be creating a precedence resulting in having to great a bunch of new roles for similar situations, but the chances of that happening are fairly low, given past history."

He covered probability, impact, and options for addressing the situation, all without throwing all the risk management speak around. It didn't matter how we defined the approach to dealing with the risk, just as long as we had one. The true purpose behind risk management is not to identify risks, but to guide project actions and ensure that the level of risk facing a team is acceptable. Not too much risk, meaning the project is doomed to a ghastly death, and not so little risk that there is no corresponding reward. As Lister and Demarco said in Waltzing with Bears, if you are doing a project with absolutely no risk, it is most likely not worth doing.

Once you strip all of the risk management language away, risk management is pretty simple. It's about thinking "What could happen?" and deciding what actions the team should take. The goal is to make sure that the good things do happen and their impact is magnified, and that bad things don't happen (and if they do their impact is minimized). It's the team members -- developers, testers, business analysts, subject matter experts, people who live the process every day -- who know what those good and bad things are, and who usually have a fairly good idea how to address them. Make it easy for them to identify those things. Don't get bogged down into the terminology of risk management.

Although teams don't need to know all the risk management terminology, it certainly helps to give them some thought starters if you are trying to identify what risks may exist. I encourage the team I'm working with to think of three types of risk, primarily because thinking of it in this manner helps to make sure that you've considered most of the key risks. The three types of risk are delivery risks, business case risks, and collateral damage risks.

Delivery risks are the ones that project teams most often think about. These are the things that prevent the project from finishing; all those nasty things that could cause the project to be late, go spiraling over budget, or fail to deliver the agreed upon scope. "Ah ha!" the team members say at this. "See, it's that iron triangle thing. That's a PM's job!" Yes ... but any PM worth their salt will tell you that they have no hope of knowing what all those nasty things are without the input from the team. Their role is to facilitate the discussion that identifies those risks, determines whether the team should care about them, and decides what to do if they do care. The PM understands the concepts of probability and impact, and can categorize mitigation strategies. Project team members know what the probability and impacts are, and are the ones that will come up with the strategies, regardless of how they are classified.

The second type of risk is to the business case. This means that the project delivered, but it delivered the wrong thing, or didn't deliver sufficient value. This is the risk that the team is not working on the right things. Product owners typically have the biggest impact on this one, but the team knows when the stuff they are working on doesn't make sense. They have the advantage of looking at things from a more objective view point than the product owner, who frequently feels like the project is their baby and would be the last to call it ugly. It's up to the team members to question why the project is being done, understand what problem it was trying to solve, and identify the risks of delivering the wrong thing or solving the wrong problem.

The third type of risk is collateral damage. This is where the project delivers value but unintentionally causes harm to some other part of the organization, perhaps by introducing extra work for other parts of the organization, or by introducing a new product that unintentionally steals market share from an existing product. As with risks related to the business case, team members often have the most insight into potential collateral damage, especially the ways that a project could impact another part of the organization. As soon as one of those concerns occurs to a team member, they have a responsibility to bring it up to the entire team to discuss whether it stands a good chance of happening and, if so, what should be done about it.

So the next time you are getting ready to work on risk management, resist the temptation to fill your project team up with the theory of risk mitigation approaches and impact and probability ratings. Instead, remember that the answers are in your organization, remind them of the different types of risks that I mentioned earlier, and ask them what could go terribly wrong (or fantastically right) with your project, and what they think the team should do about it. You'll get to the same point, and may have more buy-in in the process.

Related Links
Our Risk Checklist is another way to be sure your risk assessment is covering all the bases. Use a Risk Strategy Selection Matrix to decide how to approach the risks that are worth worrying about. For more, see our Burning Questions on Risk Management.

Collaborating with Non Collaborators

2011-05-10T09:39:52-07:00

by Kent McDonald & Todd Little

For this column, I am going to model my advice by collaborating with a good friend of mine, Todd Little, one of my co-authors on Stand Back and Deliver. Collaboration is sometimes a bit tricky, especially when people are involved. But a diverse team that can collaborate well can harness the creative tension to generate innovative ideas and solutions.

We frequently find ourselves working on volunteer efforts with a group of very talented people. Recently on one of those projects, we ran into a situation where a couple of our peers, George and Simon, were having difficulty working with each other. We were in the unique situation to hear both sides of the story independently and found it interesting that they both identified the same concern. George claimed that he was trying to work with Simon, but that Simon was not acting in a very collaborative manner. Meanwhile, Simon kept saying that George just refused to work with him. In effect, they were labeling each other non-collaborators.

We soon realized that while Simon and George each claimed the other was a non-collaborator, what they were really saying is that they didn't agree with each other. Considering projects we had worked on in the past, we identified similar patterns. When we work with someone who agrees with us, we either assume they are collaborating or we really don't care because they are complying with our desires. On the other hand, if we work with someone who does not agree with us, we may conclude that they are not being collaborative if it seems as though they are preventing us from making progress. Our key insight came when we realized that we should separate the ideas of collaboration and agreement and look at how they interact with one another. Our favorite tool for representing this interaction is, of course, a 2x2 matrix.

If someone wants to collaborate and is in general agreement with us, we call this situation collegial.
If someone doesn't collaborate, but agrees with us nonetheless, then they are in compliance and not a real obstacle.
If someone doesn't collaborate and also disagrees with us, they oppose us and tend to be obstinate, creating a combative situation. This is the category of non-collaborator that causes us the most challenges.
The most interesting situation occurs when there is active collaboration but significant disagreement. This combination can be quite powerful, as it generates a creative tension that leads to innovative results.

The combative situation is the least desirable of the four, so when we find ourselves there, we want to move out. The typical reaction is to convince the people we are fighting with to agree with us, thereby moving into a compliance situation. Failing that we try to remove the fight, either by removing the combative person altogether, or by sidelining them to the extent that it doesn't really matter if they fight us.

These actions may improve team harmony, but they also waste a fantastic opportunity to create some real game changing ideas. A much more powerful, effective, and rewarding solution is to move the situation to one of creative tension to generate more innovation.

So how do we do this?

We need to understand why there is no collaboration. A common reason is one or more parties involved prefer not to work with people who don't agree with them. You can almost hear them say things like, "I'll work with anyone as long as they agree with me." This is what we were seeing in the case of George and Simon. Both were very strong personalities and had strongly held opinions. They agreed on the time frame of the project. They agreed on how much they should spend on the project. They agreed what they should try to accomplish with the project. They were diametrically opposed as to how they were going to make it happen. Each assumed they were calling the shots.

Once they realized they had a difference of opinion, George and Simon immediately fell back on politics and parliamentary games. They started gathering supporters, identifying their detractors, and looking for facilitation techniques and meeting management practices that would steer the conversation in their desired direction. They were, in effect, trying to convince one another to alter their opinions, while at the same time almost exactly echoing each other: "I am trying to work with {George/Simon} but he just won't work with me." Each sensed that they were being manipulated, and so immediately began feeling that their opinion was not valued. They were not listening to each other.

It would be much more effective for George and Simon to admit that they had a difference of opinion, and then—for the moment at least—agree to disagree. Once they do that, they could step back and talk about the purpose and objective of their collaboration—why they are working together in the first place. Both of them believe in the purpose and vision and are committed to successfully completing the project. The problem is that they each see different ways to get to the end, and they each see flaws in the other's proposed solution. If they can agree that they are both seeking a successful outcome to the project, they then should come to an agreement on what success looks like for this project. If they can reach agreement on this point, they can have confidence that they are working toward the same aims and it is worth moving forward. If not, they should have a frank discussion about whether it makes sense for them to continue working together.

This process establishes a common objective around which the fighters can focus. Once that common objective is identified, they can then agree to listen to each other regarding their thoughts on the best way to reach that objective. The key here is to practice active listening. George should truly listen to Simon's viewpoint without his own answer running at the same time. Then, Simon should listen to George's perspective with the same attention. By showing that kind of mutual respect, they will build up a level of trust that makes effective collaboration possible.

Once they've established that level of respect and trust, George and Simon can then harness the creative tension to look at both approaches and understand how they can accomplish their shared objective. As long as they have defined success as something that benefits both of them, they should be able to come up with an approach that will work. The real value of the collaboration is that this creative tension often generates a hybrid idea—or even an entirely new one—that is far better than either of the original approaches.

The process we just described is not always easy. Egos and political power plays can often be involved, and true collaboration is effectively impossible in such an environment. If participants get overly obstinate and cannot resolve their differences in a timely manner, the whole process can grind to a standstill. Sometimes the team just needs to make a decision and move on, or possibly get an outside influence to help arbitrate.

We suggested this approach to George and Simon, and left them to their own devices to see where they go with it. The early returns look good. They had a frank discussion and realized that, while they were heading to the same destination, they were trying to get there in two completely different ways. George realized that Simon had a significant concern that George had not really been worried about. Now that he is willing to listen, he understands better why Simon was concerned. George still doesn't like Simon's proposed solution, but he realized that it did address the issue that Simon had raised. They are now in the process of trying to figure out if there is an alternative solution that addresses all of their concerns. The conversations are lively, but we can see newfound respect, and a spirit of true collaboration.

Is Your Project AWOL (Active Without Leadership)?

2011-03-01T16:59:54-08:00

by Kent McDonald

I recently caught up with a friend of mine who I had not talked to in quite a while. While we were catching up, he told me that he had recently changed jobs and that while he really liked his new one, the switch was not his choice. I asked him what happened, and he proceeded to tell me quite a tale of the impact of leadership (or its lack) on a project and a team.

My friend had been working on a project to deliver new functionality for his former employer's customer service system. The new functionality had been a big selling point for a couple of new customers that were scheduled to implement the software in the fourth quarter of last year. My friend's team had worked out a realistic plan to deliver the new update a couple of weeks before the scheduled implementation date.

Two months before the scheduled delivery date, two of the functionality team's most experienced team members were reassigned to work on revising the company's CRM product, which had been losing market share in a shrinking market. My friend pointed out to his manager that losing access to those two team members and their skills would set back the project by about two months. As a result, the new functionality promised to their customers would not be available until a month and a half after the scheduled implementation date. His manager's response was the equivalent of a shrug: her boss said the other project was a higher priority and there wasn't much she could do.

Undaunted, my friend pulled the team together and they talked about their options. When they had originally planned the project they had worked with the Product Manager to prioritize the features involved in the upgrade, with the features most important to the new clients assigned a higher priority. The team had originally planned to release all of the functionality at the same time, to reduce the impact to their customers, but they worked out a way to do two releases instead. The first one, containing the functionality desired by the new customers, would be available three weeks after the original delivery date, just a week after the scheduled implementation date. The remaining functionality would come in a second release three weeks later. So far, so good.

Early on, my friend had established an agreement with the Product Manager that he could communicate directly with the key customers to get feedback on features and to keep them apprised of progress. So, in accordance with that agreement, he notified the key customers that staffing delays had impacted the project schedule, but that they had worked out a plan that would impact their implementation time by only a week. Naturally, he copied the product manager and his own manager on the message, just to make sure everyone was in the loop.

The next day, my friend's manager stopped by his desk to talk about the project. At the end of their conversation, she remarked, "Oh, and about that update you sent out about the customer service system yesterday? I would not have sent that email." She left his office without any further explanation. My friend puzzled over that comment for a few minutes, then brushed it off and got back to working with his team to meet their new schedule.

Over the next few weeks, my friend noticed that his manager seemed to be ignoring him, except when she would stop by his desk to ask for progress reports and berate him to speed up the pace.

This continued until about two weeks before the planned delivery date, at which point my friend's manager called him into a conference room. He was a little concerned about the abrupt scheduling of the meeting, and his concerns were realized when his manager told him that he was being fired. When my friend asked why, his manager simply said he "had not been displaying the type of judgment expected of project managers at the company."

My friend was stunned. He hadn't received any feedback that his manager was unhappy with the job he was doing, and the only feedback that neared any sort of "coaching" was the offhanded comment about not sending the update about the Customer Service System project. He ended up taking a couple of weeks off, and then found a great job at another company.

As he told his story, it became apparent that my friend had in fact been fired because a lack of judgment; not his own, but his manager's. First, there was the removal of team members from a project that was contributing to increased business for the company to one that was best described as throwing good money after bad. A more appropriate response would have been to weigh the relative impact of the two projects on the overall outcome of the organization and make a resource allocation decision accordingly. An even better decision would have been to keep the team members focused on the customer service system upgrade and either pull additional team members from other projects, or bring in consultants to work on the CRM project -- or ask whether the CRM project should be continued at all.

Next, the manager's reluctance to provide my friend any help or support in dealing with the removal of two key team members is also a sign of poor leadership. Project managers should not go to their leader with a problem and expect a solution, but they should at least be able to identify problems and potential solutions and expect some assistance, support, or actionable feedback. My friend ended up coming up with a solution, but it is remarkable to me that he had the fortitude to do it given his manager's defeatist attitude.

Finally, the lack of feedback my friend received leading up to the end of his job is a final sign of poor leadership. It is difficult to know for sure if you are doing a good job if the only feedback you ever receive is "I wouldn't have done that" followed a couple of weeks later by a pink slip. This is the ultimate example of ignoring problems in the hope that they will go away, rather than coaching people so that they could improve their performance.

In the long run, my friend is in a much better position now than he was at his former company. He realizes that he ran into a situation where politics and poor leadership combined to lead to some fairly dysfunctional behaviors and to an unplanned two-week vacation without pay. Looking back, he says he wouldn't do anything different, but going forward, he is going to pay a lot closer attention to the politics that may be going on around him and his project, and be a lot more selective about what opportunities he takes and what leaders he works for.

A Personal Retrospective for 2010

2010-12-20T10:49:37-08:00

by Kent McDonald

Given the choice between writing a kitschy Christmas-themed post, and an equally kitschy end of one year/beginning of a new year thing, I chose the latter. While riffing on the 12 Days of Christmas or The Night Before Christmas sounds appealing, I thought a take on the annual celebration of what has passed and what is yet to come might be more helpful.

If you think about it, the end of a year has a lot of similarities to the end of a project (never mind the fantasy that many project managers repeatedly fall into that they could actually complete a project in line with the end of the year). You have a fury of activity toward the end of the effort (the craziness of getting Christmas presents purchased and attending an inordinate amount of celebrations with different combinations of friends and family) followed by either a blow-out celebration or a quiet lull where you thank the stars that you got another project (year) under your belt. Then you have the pressing need to make your plans for next year, whether it's your resolutions for the New Year, or the plan for your new project.

I have covered the topic of resolutions before. In this article, I'd like to talk about an activity that is always a good way to determine what some of those resolutions should be, or in the case of the project, what techniques or approaches you utilize on your next project. That activity is known to many a project manager as the "Lessons Learned" or "post mortem." I prefer the term retrospective, because it does a better job of conveying the "reflect and adapt" nature that helps project managers practice continuous improvement. I also am a big fan of doing retrospectives throughout a project so the team can revise their process while there is still time for the changes to make a difference.

Regardless of when you do it, a simple approach is to guide a conversation with the team using a set of questions. This approach is described in the Retrospectives Technique Brief, but I'll give an overview here.

Start off by posing a set of questions to your team. Ask the team to write their answers to the questions on sticky notes and put them up on the walls on separate sheets, one for each question. Then facilitate a discussion, looking for trends amongst the feedback and work to determine what action plans should be undertaken to revise the team's approach, and to shed some light on the things that still puzzle many of the delivery team members.

To give an example of what responses could look like, I performed a personal retrospective. Here's what I came up with using a set of questions representing a combination of two commonly used sets of questions:

What should I start doing?

Pay closer attention to how I communicate with my stakeholders before, during, and after the project.

Stop thinking of risks as just bad things that could happen, and take more calculated risks where it makes sense.

What should I stop doing?

Any activities that do not directly add to the accomplishment of organizational objectives.

Creating project documents for the sake of the documents, or because the "methodology says so" (this is actually a special case of the above item).

What should I continue doing?

Seek to understand the problem a project is trying to solve by asking the right questions.

Pausing periodically throughout a project to reflect on how things have been going and adapt my approach accordingly.

What did I learn?

Politics are not reserved just for Washington DC; they play a very active role in corporate life, and even projects. Ignore them at your peril.

Life is too short. Do what you like, and like what you do.

What still puzzles me?

Why do people continue to ferociously fight for projects they know are not aligned with their organization's strategy (i.e. boondoggles)?

How can I usefully measure the value that a project delivers, and perhaps more fundamentally, how do I define "value"?

As you can see, by guiding the conversation with these questions, you arrive at actionable answers for revising your project's processes based on your experiences. The next steps are to identify who is going to be responsible for making sure the identified activities are accomplished and by when. And if the team is paying attention, they'll make those plans commitments, not resolutions.

Related Links

We don't actually make our columnists choose between kitschy Christmas-themes and kitschy New Year stuff, but the mind seems to naturally wander to reflect-and-adapt themes this time of year. If you're in that boat personally, check out Kent's Agile Technique Brief on Retrospectives for a more detailed look at the process he describes above. (A more traditional version is our detailed Lessons Learned Survey and the related Meeting and Report. To translate those lessons into action plans, use an Action Item List or (for personal goals) Kimberly Wiefling's Priorities, Goals, and Actions Alignment Worksheet.

Looking for some good old-fashioned Christmas classics? Check out Carl Pritchard's 2008 PM wish list ... and a Partridge in a Pear Tree" or his 2004 entry "Yes Virginia, There Is a Project Manager."

Letter to Me

2010-10-12T11:09:07-07:00

Reflecting on my 15-year career of project work, I am struck by how many new project managers learn the same hard lessons I did in the same way—through painful experience. That thought had been floating around the back of my head not really going anywhere until about a week ago, when I was driving my six-year-old daughter to school and Brad Paisley's song Letter to Me came on the radio.

For those of you not familiar with the song, it's about someone my age writing to his 17-year-old self about all the things he knows now and wishes he had known or done then. It occurred to me that perhaps people have to learn these lessons the hard way because they did not have someone they trust sharing their own experiences and providing advice. While this is a task tailor-made for a good mentor, a satisfactory substitute would be some kind of communication from their older and (hopefully wiser) selves sharing their experiences.

Putting aside for a minute the niggling details about the whole space-time continuum and tying a proverbial knot in a given timeline, it seemed like an idea worth exploring. So here is my letter to my younger self, just starting out in my project management career.

Hey Kent,

Congratulations on getting that new Project Management gig. I'd wish you good luck, but I have it on pretty good authority that you had some good breaks and some bad breaks along the way, so the wish of good luck is more a social nicety than anything of any real substance.

If you haven't figured it out already, this is you 15 years from now. I thought I'd drop you a line to give you some advice to make your project management work easier. This is probably an exercise in futility, because you will most likely read this, appreciate the heads up, and then do half the things I suggest you don't do. I know that, because that's what I did. Sometimes you just have to learn things the hard way. That aside, here is a list of my things I wish I knew when I was your age:

Things are not as simple as they seem.
You're not in college any more (although you're closer to it than I am, and you are really going to enjoy that executive MBA program). Except for dynamics and those nasty differential equations, college was a lot more straightforward than real life. There were problems you had to solve in your classes, but you always seemed to have all the information you needed. Project Management is not like that. You will find that you are missing a lot of information and will have to make a lot of assumptions. If there's any way to avoid making those assumptions, do it. If you are not sure, ask. If you must make assumptions, make sure you note them as such and then set up the project to verify or falsify those assumptions as soon as you can. It's ok if you make an incorrect assumption as long as you can identify it as false and correct your plans.

Don't overcomplicate things.
Since things aren't nearly as simple as they initially seem, the last thing you want to do is make them more complicated. Don't fall into the trip of thinking you have to design a solution that handles EVERY exception systematically. You can address problems with complicated logic built into the system, or you can allow the people using the system to apply logic and do some thinking for themselves. The same goes for the method used on the project. Provide your team with some simple rules and let them take it from there.

Plans are useless, planning is indispensable.
You'll figure out after the first couple of projects that there are lot of subtleties to project management, and this is one of the keys. You'll hear a lot of people talk about creating a project plan and developing a project schedule. You'll also roll your eyes at the discussions that seem to go on incessantly about why a plan and a schedule are not synonymous and that a project plan is much more than just a list of what things you are doing when. The main thing to remember throughout all of this is that the act of planning is a lot more valuable than the resulting document, be it a plan or a schedule.

The purpose of the planning exercise is not to generate a Microsoft Project schedule, but to gain agreement on how the team is going to work together, what things people have to do, and by when they have to do it. The discussions that occur during that planning work are key because they will point out risks and constraints that may not have surfaced otherwise. Documenting the key points from these discussions, i.e. "the plan," is important because it captures what agreements the team made for future reference.

It is not your job to be everyone's friend.
If you are working on any project that is truly worth doing, it will mean that you are making some substantial changes to the organization, which will also mean that you are rocking someone's world, moving someone's cheese, throwing someone's fish, or whatever cutesy change management book is the rage at the time. Simply put, you will have to deal with people's attitudes toward change. Don't take their reactions personally; that will drive you nuts. You have to assume that everyone is trying to do what they think is right from their point of view. The trouble is that their point of view may be that the way they have always done it is the right way. Try to understand your stakeholders' perspective and gain some level of understanding of how the project looks from their perspective. Then consider what you can do help all of your stakeholders see the benefits to their work as a result of the project.

Understand the true purpose of change management.
Change happens a lot on projects. In fact, projects exist to introduce a change of some sort. Change Management processes are built to handle this frequency of change. Managing change does not mean instilling a change prevention process with a 6-page change request form in triplicate and three levels of management approval in order to correct a grammatical error on a project document. (Don't worry, you won't introduce such an arcane process, but you will experience a few.) Managing change means making sure that everyone that needs to know about a change does know about it as soon as the appropriate decision maker decides the change should occur. In other words, just because you update a requirements document does not mean that the entire team—especially developers and testers—are going to magically know that a change occurred.

The other thing to remember is that there are difference kinds of change, especially when you are dealing with requirements. As you dive into more detail, a lot of what some people will want to label as "change in requirements" is really just a clearer understanding. Make sure you are able to tell the difference and structure your approach to take advantage of learning opportunities.

Know who the real decision maker is, and help them out.
You will find that the projects in which you have an active, engaged Project Sponsor with the authority and willingness to make decisions for that project are the projects most likely to succeed. Make sure your project sponsor has some skin in the game—preferably they will own the result after the project is completed. Expect this Project Sponsor to make key project-level decisions, and be prepared to help them by providing the information—all the information—they need to make timely, effective decisions.

Along with that, make sure you communicate accurate status on a regular basis to your project sponsor and other stakeholders. Although you'll be tempted to hide or sugarcoat bad news, withholding information is rarely the right course of action. The truth will come out eventually, and very few people like surprises, especially when they are unpleasant. Remember, bad news is not like fine wine—it does not get better with age.

Well, just a few hints from me to you. Hope you follow them. Then again, thinking about that whole space-time continuum thing and the idea about not messing with the past, I suspect you won't, because otherwise I wouldn't have had the experience to write this letter.

Regards,

Kent

More Great Advice
Alfonso Bucero once reflected on the scattered focus of his younger self, with some advice for being more effective. Carl Pritchard encouraged a more positive outlook after listening to the Dalai Lama and Mr. Rogers. Our New Project Manager Fast Track includes advice on what matters most when it's time to plan and schedule a project.

What advice would you give yourself as a new project manager? Share your Letter to Me in the comments below.

GoldPlater

2010-08-03T09:51:31-07:00

In the mid 60's, James Bond avoided hat-throwing henchmen and suggestively named pilots to prevent Auric Goldfinger from inflating the price of gold astronomically (one could say "atomically"). These days, project managers have to fight an equally devious villain, Goldplater, who attempts to atomically inflate the costs of projects. Goldplater usually doesn't reveal his entire plan over a martini (shaken not stirred); rather, he reveals it gradually through casual hints and added features.

I bet you're thinking, "Oh, those darn Business Owners, why can't they keep their scope under control?!" But Goldplater is not always a Business Owner. Sometimes he takes form through our assumptions.

Most of my project work involves information technology in one way or another, so whenever I start a new project, I find myself looking for tech-based ways to solve problems. After all, when it's implemented correctly information technology is great for performing repeat tasks quickly, correctly, and consistently, right?

Sure, technology can do things quickly, but if it's based on a bad process or flawed business logic, technology just produces bad results faster. Sometimes, the most elegant solutions are the simplest ones. This is especially true when there are hard constraints on the project, particularly time or cost. In an ideal world, we would always have enough time to produce a bulletproof, automated system to meet every business need imaginable. As I have learned over and over again, we do not live in a perfect world.

So why do I still find fall into the technology trap? Because technology is cool, and because I have been involved in so many projects that exist to save money by automating processes. Do enough of those projects and you start to actively seek ways to avoid creating something that will have to be reengineered later.

Sometimes we need a sense of proportion. There are a lot of cases where users need to perform a fairly straightforward task or provide a fairly simple service, and they need to do it soon. A project team could spend the time and money to develop a lot of custom code around it, or they could consider who is using the system, what they are used to, what they expect, and what they are willing to do, and rely on a simple manual process. It's amazing how straightforward something can be if you think about it a little bit and factor risks, costs, and timing into the equation.

Recently I was assigned a project to implement a management system for my company's wellness center. The system was developed, hosted, and maintained by the vendor that managed the wellness center. The new system was a considerable step up from the one currently used, and provided a great deal more functionality. Since this was a hosted application, we just needed to setup a couple of interfaces and provide some configuration requirements.

This is where those nasty assumptions crept in. We needed to provide data about our company's employees to the vendor on a regular basis. I naturally assumed that we would have to develop an extract program to produce this and build a process to deliver it to the vendor. But in talking with the Business Owner a little bit, I found out that one of the Payroll administrators regularly produced extracts for other outside vendors. Since we were facing a tight timeframe and developers were pretty sparse, the manual approach looked much more appealing.

The vendor also suggested that we attach a device to the computers used for registration to allow members to swipe their badge and be logged into the system. Again, because the Business Owner wanted to keep things simple and I was concerned about how that approach would interact with our device security standard, we decided to let members log in using a good old-fashioned keyboard and mouse. After all, that was what they were used to.

In this case, I was lucky. Goldplater lived in my assumptions, but not in the Business Owner's head. This made it much easier to get around and find the simplest, most elegant solution. But I'm not always this fortunate. Sometimes Goldplater shows up in the guise of a Business Owner, suggesting feature upon feature that—while neat and value-added—may not be feasible within the constraints of the project.

What do you do when you run into this situation? First, make sure you aren't adding to the difficulty with your own assumptions. Then talk to your Business Owner about the relative importance of the various constraints. I find that the following chart (which I learned from Jim Highsmith) helps with these discussions:

Constraint Fixed Flexible Accept

Cost X

Time X

Scope X

Resources X

Fixed indicates that the constraint cannot vary, even when an issue comes up. Flexible indicates that you can change that constraint a little bit, but would prefer to leave it constant. Accept indicates that the constraint can vary in response to issues or changes in the project. There can be only one Fixed constraint and one Flexible constraint.

Using this graph to guide the conversation with the Business Owner provides a way to establish decision criteria and the relative importance of various constraints. Then, when you have a Business Owner who keeps trying to add every little bell and whistle, you can bring them back to the chart you agreed on together and remind them that you have a limited amount of time and somewhat limited amount of money and that you need to be sure you address the key objectives within those constraints. Once those goals are met, you can start looking at adding other features.

It's not an Aston Martin DB5 with an ejector seat or a Walther PPK, but this simple tool is very helpful in helping you deliver an elegant solution that won't leave you covered in gold paint.

(Barely) Related Resources:
If you remember Goldfinger, these might be worth a chuckle. If you've never seen it, the resources will still be useful. (As will Netflix. And popcorn.)

Hats off for a change of perspective: Kimberly Wiefling points out the value of trying on de Bono's Six Hats, none of which are steel-reinforced.

"No, Mr. Bond, I Expect You To Buy." Laser tables are effective, but expensive. There are better ways to confirm customer buy-in.

Just Flip the Switch? Bond movies may be the only place that ever actually worked. For the rest of us, there are integration plans.

Requirements for Requirements

2010-05-25T09:19:29-07:00

by Kent McDonald

This week I found myself in a conversation that seemed surreal at the time. A data analyst had just suggested that we add a business requirement to capture metadata for all the data elements being added on a data warehouse project. Put another way, she was suggesting that we create a requirement to capture data about data that are requirements. Once I wrapped my brain around why someone would suggest identifying a requirement to identify requirements, I realized it was worth discussing the concept for a couple of minutes. It gave me an opportunity to discuss when to create requirements for a deliverable, as well as the various forms requirements can take.

Our data analyst indicated that project sponsors on past projects she'd worked on had required that metadata be created for specific elements, because sometimes they wanted to revise, correct, or add metadata for data elements that otherwise weren't getting touched, but which were in the same general subject area (i.e. claims, eligibility, etc.). That in itself made sense. The SME's were requesting a deliverable for a particular data warehouse project in addition to the actual software being produced; in this case metadata for the impacted data elements.

You want the project sponsor to define scope, which would include the expected deliverables of the project. One of those deliverables may be specific information that goes along with a system so people know how to use it—think user manuals, online help, release notes, and, you guessed it, metadata. Makes perfect sense.

Fairly mature organizations have software development life cycle standards that require that sort of information for all systems. If those items do become part of standards, then the sponsor on a particular project should not have to indicate that things mentioned in standards are deliverables. The standards themselves are actually requirements (you could say constraints) spelling out what the project must produce. Let the sponsor worry about the business outcome they need, rather than specific system-related deliverables the team has to produce anyway. Of course, standards should be considered guidelines and not hard and fast rules. If the nature of the project does not require the creation of a particular deliverable, there's no reason to produce it. For example if no data elements are being added or revised, the project team probably won't need to create any additional metadata.

My organization does have a standard that calls for creating metadata for any project related to data warehousing. Because it's a process standard, the project team is expected to produce metadata regardless of whether the requirement was spelled out or not. So the data analyst's suggestion to create a specific requirement to create metadata was redundant. It took me a few minutes to convince her that the team will still be expected to create metadata because it's part of the process standard, and that people producing reports will have a resource to refer to, assuming they take advantage of that resource.

Then the data analyst went on to say, "Yeah, we document all the information in the user requirements so that we can then turn around and update the metadata worksheet."

Whoa there camper, hold on just a second.... Even if there wasn't a pre-existing process standard to create metadata, you certainly don't want to find yourself in a situation where you are doing extra work. Writing all the information about data elements in a standard requirements specification and then duplicating all of that information in the metadata deliverable makes no sense. Metadata is actually a different representation of data requirements. Think of a data dictionary that provides information about a data element's definition, data type, valid values, and default values. Similarly, a logical data model is actually a way of representing requirements that provides information about how the data is organized in terms of entities, attributes, and relationships. Both of these representations, which add context to the information, are much better at describing data than a requirements specification that tries to convey everything using only text statements.

The idea that the data dictionary and logical data model were really different and more appropriate forms of requirements was a new concept to the data analyst. I think a lot of people performing analyst roles find themselves using the same tool to describe everything about the system under development, be it shall statements, use cases, or user stories. It often takes some convincing that there are different ways to represent, i.e. model, requirements based on the type of requirement you are describing.

In this case, we needed to represent requirements related to data. There are several ways of doing this:

Data dictionaries

Logical models

Context diagrams

State change diagrams

Report prototypes

File layouts

Business rules

The context of these methods provides as much information as the content, and often can more clearly portray the information the team needs in order to approve or implement the desired development activities.

As I described this concept to the data analyst, I pointed out the value of using these different representations: information is not duplicated in different artifacts, making the maintenance of these requirements much easier, and reducing the risk of errors caused when the same requirement is listed in multiple places which get out of sync. I think I said something like, "Leave it to someone lazy like me to find a way to do the least amount of work and still accomplish the desired goal." Of course it's not really laziness. You have to consider how the information will be used and who will be using is before you decide the best approach to use for representing requirements. So there is some effort involved, but it is certainly worth it in the long run, and it may help avoid, or at least minimize, surreal conversations like the one I found myself having.

Related Resources
The ProjectConnections library includes templates and guidelines for meta-requirements documents like data dictionaries, context diagrams, and business rules management. As you're sorting through them all, make sure you also have a Requirements Management Plan, and that you (and your team) know how to use it.

Hawaii Uh-Oh

2010-03-18T08:54:00-07:00

by Kent McDonald

There is an inherent danger in writing about your job on a regular basis—you begin dissecting everything that happens in your life and try to apply it to a lessons learned in that particular field. Experiences on trips seem to be an exceptionally easy target for these lessons learned stories. I mention this downside because I am about to use my recent vacation to Hawaii to discuss risk management, and managing scope and schedule changes when things go bad . . . well, let's say, when things stray from the plan.

Getting There is Half the Battle

My wife and I were on the second of our four flights on the way to Kauai the Friday before Valentine's Day when I heard one of those things you never want to hear over the loudspeaker of an airplane. "If there is anyone on the plane who is a nurse, doctor, or paramedic, please identify yourself by ringing your flight attendant call button, we have some questions for you." That sparked the following series of events:

A fellow passenger was having a medical emergency. I do not know all the details, and I will spare you the few I do know since I am munching on popcorn as I write this.

Our plane landed in Denver to get this passenger medical attention.

Our plane then landed at Los Angeles, already an hour late, and spent another 30 minutes waiting for airport staff to figure out how to work the jet bridge.

Passengers continuing on to Honolulu took the layover time in Los Angeles to call on their connecting inter-island flights from Honolulu. We all found out that a popular thing to do in Hawaii on Valentine's Day weekend is to be on any island other than Oahu. All inter-island flights on our airline were booked for the rest of Friday and all day Saturday.

We landed in Hawaii 2 hours late, and despite what seemed like a brilliant divide-and-conquer strategy, discovered that every flight on every airline was in fact full until Sunday.

We found a hotel on Waikiki beach that had rooms available (probably because everyone was heading to Kauai) and checked in there to regroup and figure out what to do.

Now I realize that few people reading this will feel sorry for me. There are many places much worse to be stuck than Honolulu, especially since we were coming from Iowa and just missed the 19th snowstorm of the season. All the same, this was a serious impact to our travel "project." We were going to miss out on two nights at the condo we had rented (pre-paid), on top of which we would have to pay to change our flights. (It wasn't our connecting airline's fault that our Los Angeles flight didn't land on time.) Because of this large impact, and because this is an article on a project management website, I thought it could be informative to dissect this from a project manager's viewpoint.

What's the Worst That Could Happen?

I did not do a formal risk assessment of the trip—I am not that obsessed about applying project management to everyday life. But I did consider the risks involved in travel when I was making my plans, based on past experience. The mere act of taking four flights on two airlines through Minneapolis in the winter would seem to be fraught with risk. My risk mitigation strategy was to ensure that we had what seemed like sufficient time between connecting flights, and to make sure that the last leg was not on the last flight of the day. That approach had always worked for me in the past, so I figured I was relatively safe. Also, when I considered these risks, I considered the risk was that a flight was delayed. I did not get hung up on why a particular flight was delayed because regardless of the cause of the delay the impact on the project—my trip—is effectively the same.

While this risk mitigation strategy has always worked for me in the past, this time it failed miserably. My wife and I were left to develop a contingency plan on the fly. Luckily, we had about five hours to ponder the situation as we flew over the Pacific Ocean. (Although, much to my annoyance, my wife was formulating and running ideas past me as I was trying to sleep.) We identified a series of options and an order in which we would explore them, starting with checking all of the inter-island airlines for available flights when we arrived in Honolulu, and ultimately finding a decent hotel at which to stay the two nights until we could get to Kauai. We had to establish some criteria for evaluating our options, including the relative importance of our constraints. Cost was not a fixed constraint, which allowed us more options, and also allowed us to stay a nice hotel on Waikiki Beach (although sharing our sob story did help us get a fairly good rate at the hotel).

Just Another Day in Paradise

So there we were, unexpectedly spending two nights in Honolulu. We got up the next morning and surveyed the situation. May as well make the best of it, we reasoned. I am a big history buff, and had always wanted to visit Pearl Harbor, but had not had a chance in our previous two visits to Hawaii. My wife and I are also avid hikers, and it turned out that our hotel was within walking distance of Diamond Head.

If the outcomes delivered by the trip were measured based on enjoyment, the overall value of the project was reduced because we were not able to enjoy our rented condo and sit on the beach or hike on the Garden Isle. However by changing our scope and enjoying experiences we hadn't originally planned on, we were able to take advantage of the opportunities presented by a negative risk that came to fruition, including seeing a very important place in American history and giving my wife an opportunity to prove that she's in much better shape them I am while we scaled Diamond Head.

Extending the Metaphor, but Not the Vacation

Of course, another benefit of our adventures getting to Kauai is that I was provided with a set of great metaphors to discuss some of the finer points of project management. I'll sum those up, so I can resist the urge to extend the metaphor to the point of absurdity.

Focus on the important risks on your project and establish plans for addressing them, but don't waste effort parsing out root causes that have no impact on your approach.

Expect that some of your plans for addressing risks will fall through and you will have to enact one or more contingency plans. It's best to have those contingency plans established beforehand, but don't be surprised if you have to determine contingencies on the spot, especially if you discover key pieces of information that change your initial approach to the risk.

Understand the relative flexibility of your constraints when considering different contingency plans. In my vacation scenario, my wife and I were willing to spend a little bit of money to be comfortable while we were inconvenienced, which opened up more possibilities and allowed us to focus on options that would get us to Kauai sooner.

Scope and outcome are not the same thing. Outcomes are the results of the project—how the world is different as a result of the project compared to how it was before. Scope is the list of deliverables or activities required to deliver the desired outcomes. In the case of the trip, the outcome was enjoyment and relaxation and the scope was what we did to experience enjoyment and relaxation.

Different scope items can lead to the same outcome, just via different means. If you are focused on the desired outcome when you start the project, you give yourself a lot more flexibility on how you arrive at that outcome. In other words, start a project with the problem you are trying to solve instead of fixating on a particular solution.

When I went back to work (the day after arriving home nine hours later than planned—a story for a different article) I found myself telling people that our vacation was "great once I got there, until we had to come home." I'm sure that as time passes I will remember the great times I had when I was actually in Kauai, and the interesting project management lessons learned along the way. Aloha.

Related Links
Kent may not be obsessive about applying project management techniques to everyday life, but some of us are. If you need some ideas for brainstorming project risks (on the clock or off), consider our Project Risk Checklist. When considering the difference between scope and outcomes, keep the bottom-line requirements in mind. (This case study may help.)