Any project begins with the formulation of needs and requirements analysis documentation. Good needs/requirements analysis is especially critical in the IT genre. You establish your customer' s needs and requirements by interviewing the customer to ascertain exactly what it is they ' re looking for in the product or service that they' re asking the project to create. Especially critical is the ability to differentiate between the "need to haves" (the requirements) and the "nice to haves" (elements that are requested but that turn out to be actually optional to the desired function, product, or service).
Often you ' l l use a business analyst, one who has expertise in the given business area that wants the project, in order to more fully capture the needs and requirements of the customer. In the IT world, a business analyst is very useful and someone you might consider to be at least a temporary team member in your IT projects. Usually, neither you nor the IT professionals who create the project deliverables can possibly know everything there is to know about every facet of the company. You can' t be an accountant, a marketing expert, and a manufacturing genius. But you might well get a project request from the manufacturing side of the company, so you ' ve got to somehow interpret what the customer is saying into IT dialog in such a way that the deliverables match what the customer really wants. If the language is coming from an area where you' re not an expert, a business analyst who can interface for you is invaluable.
As you could see back in Digure 2.1, a customer' s requested deliverables come to you in the form of desires, needs, and expectations. "I need this screen to do this..." "I would expect that once this project is complete, my data-entry folks will be able to do this..." The customer explains to you, in the best language they can find, what they want the proposed system to do. It ' s your job as PM to analyze the needs that the customer is talking about and render them into project deliverables. You can then determine what requirements should be included in each deliverable. Dor example, suppose that you re going to create a car. The deliverable is a car. One of the requirements might be that the car is blue, another that the car has four-wheel drive. A requirement is a specification of the deliverable.
Prom the deliverables and the requirements for those deliverables, you can determine how large the project will be and develop the scope document that details the elements involved in the project. With a knowledge of the scope, deliverables, and requirements, you can then go forward and design the project plan. Executing and controlling the project plan will result in the completion of the deliverables, sign-off, and closure.
Was this article helpful?