Do Your Homework

Do Your Homework

Generally, the most common, visible first step for a project occurs when a project manager tells a senior member of his development staff that he has something new for the team to work on; this often happens as nothing more than an informal chat around the office's water cooler. In practice, of course, the idea starts much further back. Tracing the roots of any given project is essential. A project management methodology can be successful only if it is applied from the very start of the project.

Before you take steps to receive the formal brief for the project, there are a few key questions to ask your homework, if you will. These questions taken together will form the foundation of the strategy you adapt when receiving the formal brief. The first question to ask is "Why?''

Why is the Project Happening?

This simple question has an enormous influence on everything you do from here on in because the way in which you build your project, from start to finish, must be determined by its intended function.

Typical reasons for a new Web project might include:

  • Starting a new business for which "the business is the application.''

  • Replacing an existing application that is failing or no longer adequate.

  • Taking over where an existing supplier has failed to deliver either on time, on budget, or what is required (or in some cases, all three).

There are, of course, other reasons that may require a new project to be taken on and not all of them are as critical as the three listed here. For example, you may simply find yourself having to implement the pet project of a VP or executive. Whatever it is, determining the raison d' tre of the project is a number-one priority.

Who is the Project For?

This is sometimes not as easy a question to answer as you might think. At the simplest level, the project is for another department within your own company or organization, a new customer, or an existing customer. Remember that you must identify the recipient of the project in the sense of who has actually commissioned the work. If a man goes to the store to buy his wife nail polish, he's not the real customer he's simply responding to the real customer's request.

Similarly, your client may be commissioning this work only to satisfy some requirement of a third party to whom he or she is responsible. These ultimate end users of the product are known as domain experts, and you ignore them at your peril.

The end user for your product will often be the most hands-on people in your client's organization and, as such, their needs for the project will often be immensely different from the requisitioning individual who approaches you as a potential supplier.

Identifying Roles and Agenda

By way of example, say that you are the CTO of a medium-sized organization and have been commissioned by the Human Resources director to build an intranet for your whole company. You have both permanent and contract staff at your disposal. What do you think the various agendas of each role (you, the client, and the domain experts) are?

To take a slightly cynical perspective on things, the scenario most likely looks something like this:

  • You want to deliver a high-quality, effective, efficient, and satisfactory solution as quickly as possible and with as little investment as possible so that you look good.

  • The HR Director wants you to deliver a high-quality, effective, efficient, and satisfactory solution that makes him or her look good.

  • Daily users of the intranet (the domain experts) want you to deliver a high-quality, effective, efficient, and satisfactory solution that does what they want it to do.

Notice that the only pure agenda here is held by the domain experts. The secret is to ensure that all three agendas are met. The first two are incredibly easy to meet, but by concentrating on the third, the first two will generally drop into place.

Manipulating Roles to Your Advantage

Consider this. Your client is merely a conduit to the domain experts on a project, no matter what else they might tell you. Although it is a lot easier for your client to express immense pleasure with what you've built at the point of delivery and walk away, if the domain experts don't like it, the axe will fall on the client's head and so, in turn, it will fall on yours. It is very much in the client's interest to represent the needs of the domain experts from the outset.

A good client will be able to sympathize with the true needs and requirements of his or her domain experts and assemble them into a single, harmonious voice for you to listen to. However, in practice, you will need to prod, probe, and cajole your client into representing the realistic and reasonable requirements of his or her domain experts properly.

If you feel that your client is not representing his or her domain experts sufficiently, it is vitally important that you suggest that he or she re-implements the consultative process. This can be accomplished through:

  • A brainstorming session

  • An anonymous suggestion box approach

  • Appointing a working party to represent the needs of the domain experts

It is vitally important that if the roles aren't clearly carved out from the start, you must help carve them out. That way, when you do receive the formal brief for the project, you'll be able to respond to it, safe in the knowledge that what you're responding to is in fact what is really required.

What is the History of the Project?

It is also vitally important to establish whether this project has any baggage attached to it. A fresh project is always exciting, but it may not actually be as fresh on the inside as it appears on the outside. Having a good handle on the history of the project allows you to tweak certain aspects of your approach accordingly.

Generally speaking, a project has serious baggage only if another attempt has been made to get it off the ground previously. If you know this to be the case, then you should immediately make yourself aware of the following potential baggage, no matter how long ago that previous attempt was made.

What are the Anticipated Prerequisites of the Project?

You should be aware of these as early in the project life cycle as possible because they may even influence your decision as to whether you wish to proceed. Some typical prerequisites might include:

It is very important to get these prerequisites established before you embark upon the process of receiving the brief. After all, if you can't fulfill the prerequisites, there's little point in moving to the next step.

Professional PHP5 (Programmer to Programmer Series)
Professional PHP5 (Programmer to Programmer Series)
Year: 2003
Pages: 182
BUY ON AMAZON © 2008-2017.
If you may any questions please contact us: