Improving Requirements Quality with Use Cases

People sometimes like to dive right in to requirements definition by simply starting to write them on a blank sheet of paper – or blank Word doc for those of us who have gone completely green. Starting the requirements definition process this way can be very intimidating at best and full of oversights, omissions, and conflicts at worst. Even if you define and document scope in detail as I’ve discussed in the past, it’s still a big leap from a scope document to detailed requirements. Customers often have a hard time with requirements and you certainly can’t write all the requirements for them. You can help … but be sure to bill for it.

Sample ATM system usage use case diagram

Use cases are a simple, cost-effective way to build a consensus among stakeholders and to discover missing requirements. They tend to address two large classes of requirements errors – omitted requirements and conflicting requirements. While drilling down further into requirements, the customer – usually with your help – can utilize use cases to get detailed requirements across all life-cycle phases to support the requirements definition process.

Why develop use cases?

Use cases are relatively easy to generate. The customer must access their stakeholders and subject matter experts (SMEs) to get well-thought out use cases that can be used to derive detailed and meaningful requirements for the engagement. Below are some of the reasons and pluses for generating these use cases: Read more »

Good Requirements vs. Rework – Part 2

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

This article is based on information from Hooks and Farry’s book entitled, “Customer-Centered Products.”

“Better, cheaper, faster!” Remember how we discussed that in my previous article and closed out with the good news that “better, cheap, and faster” is actually possible?

Now the bad news: You have to change your approach to project and product development or procurement in order to realize “better, cheaper, and faster.” Repeating the mantra is not enough. Nor is it enough to tell your requirement definition team to simply “write better requirements.” If that was all it took, we all would have done that long ago. You, as the project manager, must identify the areas needing improvement and empower your people to change. Only a manager can eliminate many of the causes of bad requirements. The seeds of schedule and cost overruns as well as operational failures are planted early in projects, typically with pressure, often from management to procure or begin developing a product before fully defining it’s needs and use. Read more »

The Most Valuable Role of a Project Manager

The post is made possible by the great people at Seavus, creators of online Project Management tools such as ProjectOffice.net, Project Viewer, and Project Planner.  Please visit their site for more information.

Recently, I was reading a discussion thread on this on the LinkedIn site. Someone had posted the question, “What is the Most Valuable Role of a Project Manager?” Someone posted that question along with a follow-up question…”And how can a Project Manager optimize that role?”

At the time of this writing, the discussion has been going on for 9 days and has 11 comments so far. Breaking it down by responses that actually tried to answer the question rather than just chime in on the discussion, here are the results (the number in parentheses is the number of that specific response):

• Communicator (5)
• Deliverer of change to the business (1)
• Ability to say ‘no’ (1)
• Leader (1)

So, out of 11 comments, 8 actually gave answers. And of those 8 (one was me), 5 stated that communicator was the key role of the project manager (and yes, I was one of those 5).

I find this interesting. And all responses were good responses. The discussion will probably continue for a while, but I find it likely that communicator will still be on top down the road. The other responses are important ones.

Saying ‘no’

The ability for the PM to say ‘no’ – especially to the customer who they are trying to lead to the right solution – is very important. If the PM can’t be strong – stubborn as I’ve often called it – and stand firm on the goals of the project and know when to say ‘no’, then the project is likely to face issues and the project scope is in constant danger of getting out of hand.

Leader

Likewise, the project manager must be a strong leader. The responder stated that a good leader will know when to listen, when to speak, when to encourage, and when to cry out louder. The PM is the leader in charge of many different backgrounds and personalities. The role as the leader is a given, but they must adequately fulfill that role in order to hope to achieve success on the project. Yes, I agree, leadership is critical.

Change agent

Anytime you’re delivering a project you’re delivering change to the business or client. The project manager is that change agent and sometimes has to work hard to knock down barriers to change. They must work well with others inside the business or with the client to make that change happen and to help that change be accepted. The PM is definitely a change advocate.

Communicator

However, I still believe – as I always have – that the role of effective communicator is the most critical role for the project manager. All project communication happens with the project manager – it all needs to go through this one position. And if it doesn’t – if critical communication routinely circumvents the process and goes around the PM, then the project is likely headed for disaster. The PM is the central point for project status, project meetings, emails, revised schedules, issues tracking, risk tracking, and budget management. If key pieces of project information miss the project manager, then they will likely miss other critical communication points and individuals as well.

A project manager must be an effective communicator and must maintain control over the communication process in order to give the project its best chance at success.

Earned Value Reporting – Intro Part 2

In the previous Intro Part 1 article we began to look at Earned Value Reporting as described in Newell and Grashina’s book “The Project Management Question and Answer Book.” In this Intro Part 2 article, we’ll exam Cumulative Variance Reports before diving deepr into other EVR concepts and reporting mechanisms.

Cumulative Variance Reporting

Sometimes in very large projects there is a problem with representing the project plan and the other earned value factors on a cumulative basis. When the project budget is very large, the vertical scale of the report is so small that minor but important variations cannot be seen well. In this situation a variance reporting method can be used.

To plot the earned values on a variance chart as shown in Figure 2 we simply plot a horizontal line and label it zero. Now, instead of plotting the actual values of the BCWS, BCWP, and ACWP we plot the differences between the BCWS and the other two earned value reporting factors. When we do this, the vertical scale that we need is greatly reduced in size since we are concerned only with plotting the difference between the earned value factors and not the entire budget of the project.

FIGURE 2

The next one, the ACWP or AC, is pretty simple too. This stands for the actual cost of work performed. Like the BCWS it is a plot over time of expenditures. This time, instead of plotting the project’s planned expenditures we are plotting the project’s real expenditures over time. At the end of each reporting period, we take the total amount of money that was spent on the project during that period and plot it as an addition to the total amount of money that had been spent as of the last reporting period.

It is important that every expenditure that is made on the project be collected and be collected in a timely way. The timing of the collection of the actual cost of work performed must match the anticipated timing of the expenditures that were planned and plotted as the BCWS. This is terribly important since, if expenditures are collected early or late in the project in relation to the project plan, the earned value report will show a positive or negative variance when there may really be none.

The ACWP plot is a cumulative plot as well. If the project expenditures are actually what they were planned to be, then the ACWP and the BCWS lines will plot one on top of the other. If the lines do not coincide, there is something different from the plan taking place in the project. We are either spending too much or too fast or we are not spending enough or fast enough to meet our plan.

The next factor is the BCWP or EV. This is the only one that is a little tricky. BCWP stands for the budgeted cost of work performed. It is sometimes called the earned value as well. This is where we get the name of the earned value report. Like the BCWS and the ACWP, the BCWP is a plot of money over time. If you recall, we said earlier that each of the project tasks has a budget and schedule associated with it. The BCWP is a plot of the work that was actually accomplished. If we complete a task that had a budget of $1,000, then the BCWP for that task when it is completed is $1,000. We plot this on a cumulative basis as well. It does not matter whether we spend $1,000 or $2,000 or any other amount to accomplish this task, we earn and plot only the budgeted amount in the BCWP.

Like the ACWP, the BCWP should plot right on top of the BCWS line. If the plot of the BCWP is above or below the BCWS line, it means that the number of tasks that are being completed is greater than or less than the plan. This tells us that we are ahead of or behind schedule. If we have done all of the tasks that were supposed to be done at this point in time, the cumulative value of the BCWP will be precisely equal to the BCWS.

When we put all three of these plots together, we have the earned value report. The plots should plot right on top of one another if the project is being done on time and in accord with the budgeted amount that was in the project plan.

Example:

Suppose a project is in progress and as of today the planned expenditures for the project were to have been $500,000. Suppose also that there were five tasks and the tasks had budgets of $30,000, $100,000, $250,000, $100,000, and $20,000, respectively. The actual cost of each of the tasks that were worked on was $11,000, $120,000, $230,000, $105,000, and $20,000. Tasks 1, 2, 3, and 4 are complete.

What are the BCWS, ACWP, and BCWP (PV, AC, and EV)?

• BCWS is $500,000
• ACWP is $486,000
• BCWP is $480,000

From these figures we can see that the accomplishments of the project as of today are somewhat less than what was planned for. This is the difference between the earned value and the planned value to date. The planned value is the BCWS and the earned value is the BCWP. This means that we are $20,000 behind schedule.

We can also see that the actual cost is $14,000 less than the planned expenditures to date. This means that we are somewhat under budget. Unfortunately we are $14,000 under budget but also $20,000 behind schedule. If we add the $20,000 of work that should have been completed but was not, we find ourselves projecting a $6,000 over budget condition. It could be that things are actually worse than they appear at first glance. If the performance to date continues, the amount over budget will probably be even higher at the end of the project. This is usually considered a bad situation.

The Project Quality Assurance Role

Quality Assurance is often seen as an integral function that monitors and coordinates the quality used within the project management life cycle by evaluating the processes and procedures. Quality control, on the other hand, can be seen as a focused area (such as software testing) that compares the product to the specification or plan, with a focus of detecting and remediating errors or anomalies.

Therefore, the Quality Assurance role is a critical factor in the success of the overall project as it is focused on key quality functions throughout an engagement. In his book “Project Management Nation,” Jason Charvat identifies the following key duties for the role of quality assurance throughout the project management life cycle.

The Role of QA on the Project

The person who is responsible for QA has many duties and responsibilities. The following section lists many of the things that a QA person would be expected to do.

• Participate in the change management process to assess the risk of putting fixes into the environment during acceptance testing.
• Assist the test team in isolating the source of discrepancies between expected and actual test results. If the error is in software design, thoroughly analyze the ramifications of any design changes. Design diagrams and structure charts before proceeding with corrections to code.
• Complete preparations for acceptance testing, including the establishment of the acceptance test environment. Unlike system testing, acceptance testing always takes place in the targeted environment. It is therefore extremely important to schedule computer resources well in advance.
• Check the simulated data to ensure that required test data have been produced.
• Obtain expected results from the acceptance test plan and review them for completeness.
• Calculate any missing expected results.
• Be certain that the introduction of new load modules is according to test configuration management procedures. When a new, corrected load module is received, first rerun tests that previously failed because of software errors. If these tests succeed, proceed with regression testing.
• Analyze and report test results. Evaluate test results as soon as possible after execution. Wherever possible, use automated tools in the analysis process. Record analysis procedures and keep all relevant materials. Remember that records and reports should give complete accounts of the procedures followed. If a test cannot be evaluated, note the fact and report the reasons for it.
• Compare all test results with expected results and note that all defects are documented, regardless of how minor they appear or whether they will be corrected.