Home > Blogs > Why This Project?

Why This Project?

I have heard all sorts of reasons for taking on projects. If you dissect these reasons, many boil down to rationales that are actually irrelevant. It may be that we have found some cool new technology that we can justify solves a problem if we can get it to work, or that we always kick off a new project after the last one ended, so it is time to get going on this one. Insert your inappropriate justification here. In the end, there needs to be 2 reasons for running a project: it benefits us as a business, and there is a net gain in benefits for the stakeholders over the competition (which begets the first reason).

Projects will often start with a list of features, and a superficial inkling that this might help them out or that we might be able to sell a bunch of them. This is one of the primary reasons that completed projects (and 'completion' is another topic itself) rarely realize the wildest expectations that people started out with. We need to go deeper than this, and we need to start out with a credible, quantified understanding of the benefits that this product will bring. Tie this to the key differentiation for this product that will help us realize these benefits, and we are well on the way.

All of this information comes right at the beginning of the project, as we are developing the Charter. Some shops may call this a Vision and Scope, some may call it a Business Case. I'm working with a large group of people in an intensive project management certificate program, and we're at this stage. One of the biggest struggles is to capture the notion of quantifying our expectations.

In essence, when we consider taking on a project, the business needs to look at it as a financial investment decision. While some projects may be infrastructure investments, loss leaders into new markets or similar endeavors that may be difficult to monetize in the short term, we need some sort of model that tells us that taking on this expenditure provides us with some return that is reasonable for us. With a number of projects we can choose from, this thinking provides us with a sound decision support tool to help us understand where to invest our resources.

The cost side is usually far easier to model, as we generally (wild-assed guessing and unreasonable targeting aside) have a handle on the effort and resources required to get the product built. At least, as we generally can track these costs relatively clearly, we can understand the costs for this project and build a baseline to improve our credibility for future projects. The benefit side may be a bit more nebulous, primarily as it depends on a number of factors that are at least outside our sphere of control, possibly outside our sphere of influence. Even with this shaky ground, though, we need to develop a model that we can judge success against and learn from for the future.

Underlying the assumptions on the business value proposition is the idea that uptake of the product from the user (or broader stakeholder community) will be as expected. For this to come true, there is another essential piece that we need to think about at this stage: what makes this product different from what is out there?

This primary differentiation is absolutely critical, and if we fail to capture this early, we can easily run into trouble. It should be the primary piece of information to help us to determine whether any proposed change even makes sense for this project. Without a clearly expressed differentiation, we also run into danger that we can complete the project (and even declare success), but totally miss the point of why we built the product in the first place.

Whether this differentiation sets our product apart from the status quo (or our own product we are replacing with an upgrade) or the competition, it needs to be crystal clear to everyone on the team. Often in the commercial space, we need to consider different dimensions of differentiation from different competitors. Either way, we can't lose sight of this.

If we are differentiating with novel approaches to old problems, we need to make sure that this doesn't get cut from scope as the project progresses. Indeed, this would likely be one of the first things we build to ensure the cornerstone for our project is guaranteed to be in place. If we are improving the quality over a previous release, we need to be sure that we don't neglect the quality requirements or cut the implementation corners that generated that earlier shoddy version in the first place.

For any product, there has to be a solid reason for forging ahead both from our side and from our clients' side. Nail these first and live up to them as you go through the project, and you dramatically improve the chances of real success.

Become an InformIT Member

Take advantage of special member promotions, everyday discounts, quick access to saved content, and more! Join Today.