Reference no: EM132920483

CASE STUDY: WHAT EXACTLY AM I SUPPOSED TO BE DOING?

Russ discovered early in his career as a project manager that all plans are not created equal. He was a replacement for the project manager on a fairly complex data centre consolidation project. Russ stepped in near the end of the first major phase of project work, which was developing the user requirements for the new data centre.

One of his first tasks was to review the current project plan and evaluate the progress to date. Russ noticed that the requirements development work was shown as a single two-week task in the project plan with no additional details about the requirements process itself. Because the resulting user requirements document was shown as a completed deliverable and this task was marked as 100 percent complete, he decided to look at the new capabilities the project would provide to the business and its users. So he did.

After reading the first four pages of the document, Russ knew there was a problem. He finished reading the user requirements document, closed the file on his computer, and reached for the phone to call the lead business analyst for this effort into his office. When Mary arrived, he asked her, "What exactly is this document supposed to be? Is this just a high-level concept that we need to now go out and define?" Mary replied that the document was the final, approved user requirements document. All the business analysis team had to do now was give the document to the developers. The developers would figure out the rest.

Russ asked Mary to explain the process she and her team had gone through to produce the deliverable. She explained that she had worked in tandem with the development director to elicit, analyze, and specify the user requirements for the project. Basically, the key users had not been involved or consulted at all. As Mary was quick to point out, "That wasn't in the plan, so that wasn't how I did the work." Basically, the user requirements work had to begin all over again and had to be done correctly the second time.

Russ worked closely with his business analysis team to plan the requirements development work in far greater detail. This time around, the team gave themselves adequate time to elicit and analyze the requirements and planned the time to validate the requirements when everything was complete. Completing the rewritten user requirements took five additional weeks of work. Funnily enough, this didn't impact the scheduled end date. The original requirements would have been impossible to use for the design and construction of the data centre.

Remember that your focus is on planning and monitoring the business analysis work for a project, not on planning and managing the whole project. That is the responsibility of the project manager. However, in either case, the plans need to be built and implemented at the appropriate level of detail.

QUESTIONS:

1. You are a business analyst addressing who will receive weekly business analysis status reports containing performance against actuals for your current project. Explain each of the tasks that needs to be completed.

2. Discuss what technique might be used when determining the business analysis approach on a project?

3. When identifying business analysis performance improvements, what technique allows you to determine the metrics used for measuring performance and determining how those metrics may be tracked?