PM Articles > Kent McDonald > New Year's Resolutions For Your Project

New Year's Resolutions For Your Project

by Kent McDonald

It's that time of year where we all participate in the seemingly futile ritual of committing to improve ourselves by creating a list of self-betterment activities we refer to as resolutions. It may be worth a quick aside to ponder why we call them "resolutions" and not "commitments" or "promises." Perhaps it has something to do with our subconscious realization that we have no intent whatsoever to actually hold ourselves to them. If we associated some measure of success and a time frame with them instead of just stating we will do more of a certain activity, maybe, just maybe, they would have more staying power. "I will lose 20 pounds by July 1st" instead of "I'm going to exercise more and eat better." Perhaps we could even experience more effective, and valuable, projects by doing the same thing with them—although goals may be a better word than resolutions.

Goals, especially those of the measurable type, are excellent ways to know when a project is successful. Having a clear idea of what problem the project is intending to solve doesn't hurt either. Yet it can be surprising how many projects start without any idea of what problem they're solving, and finish—assuming they finish—without any idea of whether they solved it. Weird.

So What's Your Problem?

I'm sure this has never happened to you, so I'll describe a hypothetical situation. (OK, I suspect the following has happened to just about everyone. Something to remember when you are writing your next email while in a somewhat snarky mood: Sarcasm does not translate well to print. Anyway, back to the scenario.) You are getting ready to start a new project, and the business owner has established a general description of the project using whatever initiation mechanism your organization uses. The description reads something along the lines of, "Change the system to gather the customer's wedding anniversary, shoe size, and eye color."

Hmmm… sounds like we have a very clear idea of what we are supposed to be doing. Well at least we know the desired solution. Do we know what problem we are trying to solve? Why does that matter, you may ask. We know what we are supposed to do. Our scope is pretty clear-cut. Why not just dive in and make the changes so that we can lead a successful project?

Take a closer look at the request. For what business purpose could we possibly need those three pieces of information? If the application were intended to help you establish stronger relations with your customers, perhaps you want the wedding anniversary so that you can send them a happy anniversary card, although that seems a little personal for a business relationship. You could continue that analysis for the other elements and perhaps guess at a case where each item in isolation makes sense, but spend a bit of time guessing what the three had in common. If, however, you understood the problem that the project was intended to solve, you would have a much easier time making some sense of the request—or, more likely, identify a more appropriate solution.

If you are wondering what a statement of the problem should look like, I'll start by describing what it should not. If you ask what the problem is and receive "the system does not currently store wedding anniversary, shoe size and eye color" as an answer, chances are you need to Pop the Why Stack and continue asking why until you get to the real reason.

Instead, you want to come away from reading the problem statement with some semblance of understanding around what pain exists, and perhaps what characteristics of a solution could look like. Ellen Gottesdiener suggested a nice little format for expressing problem statements in the Software Requirements Memory Jogger. It's discussed in an Agile Technique Brief on Project Value Models on ProjectConnections, and demonstrated in this example:

The problem of setting up agent contracts in a timely manner affects agents and agency services. The impact of this is that if a contract is not completed within 3 days, the company loses business. A successful solution would establish an agent's contract in a timely and accurate manner and would be easy to maintain.

While this format is a nice, convenient way to describe the problem a project is trying to solve, the important thing is that you, and the entire project team, really understand the problem. To put it in terms that may hit a little bit closer to home, or at least may sound familiar to some, resolving to exercise more and eat better doesn't really identify the problem. Perhaps I believe I am 20 pounds overweight. Perhaps I am at serious risk of having heart problems, and my doctor has told me I need to change my ways or suffer the consequences. (Doctors really don't talk like that, do they?) The alternative resolution with the measurable goal suggests it's more likely the former. But it's reasonable to assume that, while exercising more and eating better are similar ways of addressing both problems, there are other ways to solve those problems as well. It's important to understand the actual problem in order to make sure the solution is sufficient, efficient, and effective. That same idea translates to projects, where knowing why you are doing something can prove invaluable to your project team when trying to make the multitude of decisions you face on a daily basis.

Are We Done Yet?

Understanding the problem you are trying to solve is great, but it can seem a bit hollow unless you know when you have actually solved it. The example with the wedding anniversary, eye color, and shoe size seemed quite contrived, didn't it? Take the problem statement mentioned earlier. It contains several phrases that are the bane of project teams everywhere; exceedingly helpful and precise phrases like "timely and accurate manner" and "easy to maintain." How do you know when you have solved those? They could be like pornography: "I'll know it when I see it." Sounds like a recipe for swirl.

Instead, why not establish some specific goals that will tell you when you have solved the problem, and also provide some way of telling you how successful you were with this project. If you took the "timely and accurate manner" and the little hint provided in the problem statement, you could set a couple of goals such as:

  • By 12/1/2010, 90% of our agent contracts will be processed within three days.
  • By 12/1/2010, 90% of our agent contracts will be error free.

These goals not only provide clear ways to determine whether the project really accomplished what it set out to do, they also provide some clear cut decision criteria if you ever have to make priority decisions between a set of requirements. Let's say that extremely rare occasion occurs where you have to reduce the amount of work you are planning to do because you are running out of time, money, or both. You take a look at the deliverables that still need to be completed, and notice that you have some that certainly support the goals above, and a few that do not. With those goals in mind it's easy to pick which deliverables to focus on—those that clearly support the goals of the project. In this way, the goals provide focus for a project team that a mere feature list does not. They explain why specific features or deliverables are on the list.

Keep in mind that if you are setting goals, you want to make sure you can actually measure them, and that you can compare the measurements before the project and after so you can identify the change that occurred because of the project. The best way to approach this is to establish a measurement plan that identifies how you are going to measure the goals, what data you need, and perhaps what tasks you have to do during the project to make sure you have mechanisms in place to determine those measurements. Be careful that you don't introduce measures that cost so much to gather that they reduce the value delivered by the overall project. You don't want to introduce an overbearing measurement regime that robs the project of value, or is so complex that the people responsible for the collecting the measurements find it too difficult to do on an ongoing basis.

I Resolve To...

Although you are probably reading this after you made your New Year's resolutions, I hope that you give some thought to the problem you are trying to solve, and identify some ways you can make sure that you actually keep those resolutions. Then, I hope you commit to making sure you and your project team have a clear understanding of the problem you are trying to solve with your projects and identify some measurable ways to know when you have solved those problems.

As for me, I made a resolution I am pretty sure I can keep—I resolved to not make any New Year's resolutions. I'm keeping to it so far.

Related Links
Kent's technique brief on Project Value Models, mentioned above, explains a lot more than how to phrase an effective problem statement, like how to choose which projects to do, when and why to do them, how and when to use cost-benefit analysis, and more. Our Requirements Management Plan and Requirements Measurement Plan templates can help you keep tabs on your resolutions … that is, your project requirements … and whether or not you've actually achieved your goals.

Not all comments are posted. Posted comments are subject to editing for clarity and length.

The comments to this entry are closed.

©Copyright 2000-2017 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Stay Connected
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues. Sign Up Now

Got a Question?
Drop us an email or call us toll free:
7am-5pm Pacific
Monday - Friday
We'd love to talk to you.

Learn more about ProjectConnections and who writes our content. Want to learn more? Compare our membership levels.