Requirements, according to T. Capers Jones, is, "...the statement of needs by a user that triggers the development of a program or system." He goes on to say that 80% of projects are at risk of scope creep, and that an accurate measuring system greatly helps track scope changes.
William G. Smillie in the "Software Engineering Productivity Handbook" edited by Jessica Keyes, says, "But how do software developers know if they are meeting user requirements or even understanding them? Obviously, I.S. professionals and end users will have to agree on requirements and explore the types of systems features that are most valuable to the end user. Not so obviously, an agreed-upon process to measure whether or not the requirements are being met must also be established." A RM can be one aspect of that process, along with formal conversations to determine the 'rightness' and reasonableness of user requirements.
The uses for a RM are legion, the most important being recording decisions, milestone dates, location of supporting documents, and who is responsible for each requirement from a specifications and a development perspective. It should always be physically posted in the project area and always available (read only...) in a central LAN location.
Use an RM for every project, not just I.S. development. To construct your first RM, have all of your project materials handy, especially the requirements document and detailed project schedule. If you are lucky enough to be in the first phases of a project, you can build your RM as you go. Feel free to experiment with format. I have had the best results using MS Excel, since it allows sorting to give you different views of your RM.
Title the first column 'Requirements' and use to record the highest level of business requirement you have. There should be between 2 and 8. Bold and increase the font size on these. Now under each, list the mid-level business requirements (bold), and then the low-level business requirements if needed. Now title more columns: Priority, Owner, Approved (date), Doer, Accepted (date), and Document. Priority should be kept simple, no more than 4 levels and preferably 3, such as Required (show stopper, without which project is useless), Like (demonstrable cost savings or income producing), and Nice (intangible or small benefits only). Now use meetings with the business owners to continually insist that each requirement be prioritized according to your 3 or 4 tiered scale. This is critical, so be professional and relentless over time. Without these priorities and documented cost/benefit, you will have little input for your schedule and scope decisions other than everyone's emotions and 'favors'.
When you have agreement on priorities, get signoff at the highest levels to record, and fill in the Approved column. You may have a few stragglers that you have not yet gotten priority for. You should not work on these until priority is resolved. If the Doer has buy-in to the scope at this point, fill in the Accepted column. If not, work these people who are responsible for doing the task until agreement. Also record the document name and location where the detailed requirements can be found. The completed (to this point...) RM should be a project management deliverable required before moving to the next phase of the project.
Title the first column 'No.' and use a WBS-style numbering system. This will make it easier to refer back to earlier versions if needed as the entire document will not renumber. Next is 'Requirements'; use to record your highest level of business requirement. Now title more columns: Priority, Owner, Approved (date), Responsible (was Doer, updated from a reader suggestion), Accepted (date), and Requirement Document (was just Document...), along with an Approved (date) column.
The RM columns to add next should directly correspond to your project plan, as a high level view of your task list. Put 'n/a' in all cells that do not apply, so that blank cells represent work to be done. For your Analysis Phase, columns could be: Test Plan, Complexity, Security (plan), and other high level topics. For your Design Phase, add more technical areas such as Data Base, Prototype, and Proof of Concept. Design is also the time to add detail rows under the main headings for all your detail requirements at the level 'handy' to track. These will correspond to test cases, which is another column to consider adding now. Each cell can contain more than one name. Don't worry if it wraps and takes up more room!
For your Development Phase, columns to fill in for more detail include making sure all detail requirements have at least one test case covering them. Columns to add here include Code and other deliverables, and the test names your organization uses, such as Unit Test & Integration Test, with columns for person testing and person approving with dates. Useful here are at least one Plans & Docs column, to insure that your initial plans are carried through and approved. Another is Defect Log, to make sure that defects are all being recorded after Unit Test and that they generate updated or new test cases as required. Carry this through the Test Phase, adding User, Business, Parallel, or other test types, with needed detail. For your Implementation Phase, add final sign-offs, user acceptance, and any turnover areas that should be tracked.
As your project progresses, use your RM to record and track all your important tasks, and all the detail that comes with a project. One great value of your RM will be in presenting much of the same data as a project plan, the system or other deliverable, and as the RM. Different views can make the difference between one of your major constituencies understanding where the project stands and their having unrealistic expectations. I keep an up-to-date copy of my RM in my organizer at all times along with an updated project schedule for all those impromptu hallway discussions or other meetings that come up regularly. The RM allows me to take planning and corrective action earlier than I could without it. Your RM is also a great 'War Room' candidate.
Improve or Reengineer Your Process?
"How do we know when to improve a process or reengineer it?"
This is a frequent question, usually about a specific process, especially from project and team leaders on their way to project management roles. As people start to view project processes as a critical success factor for projects, they naturally want to improve their processes to better fit their custom projects.
Project management encompasses process management for not only the main work of the project, but for the project processes. If project management does NOT include process management in your organization, perhaps it should...
When starting new projects for my clients and also when called in to 'fix' projects, examining project processes is at the top of my list. Many times quite a lot of the discord within a project team and between a team and management or other organizations can be traced to project process inadequacies.
Here are factors to mull over when deciding how to handle a process change: the size of the change, the number of and specific people involved, your organization culture, single or multiple organization involvement, complexity of the current process, if technology can be applied, the impact of the results you seek, if the process will affect multiple projects, and whether or not you will have management backing for your project.
Let's take a quick look at three different tactics to consider when one of your processes needs updating: Tweaking, or normal continuous improvement changes; Redesign, for those processes needing significant changes; and Reengineering, when you are in trouble or need a 'big hit' productivity improvement.
If most of the factors above are low, then gently improving your process is the way to go. Without a lot to gain, there are other areas where your efforts will be better spent. Minor, controlled changes can be planned and adapted to optimize or to address small process problems. An example would be switching your change control meeting day from Thursday to Wednesday to make a weekly document update schedule for your public internet pages. This type of change generally requires input and action from those whose work is affected by the change. Management may want to be informed, however will not be concerned. Tweaking of this nature can be successful without using many change agent tactics. Tweak at your whim!
If many of the factors above show above the minimum, and the change required is not too complex nor does it involve many organizations, redesign may be your best option. Significant problems or bottlenecks in several areas can also lead to process redesign. An example would be to reform your change control team around the Marketing and Customer Support functions rather than software maintenance.
Perhaps prior, your change control function was driven by production MIS or in-house users. Now management needs different responses as the product may be farther along the product life cycle or for other reasons. Redesign may point you to delete or add a step or two in the process and tweak many of your steps. Redesign normally keeps many of the same process steps, and in this case perhaps changing only the priority setting functions and the major players. Your effort expended during redesign working the people side of the change equation will not be wasted. Redesign any time you see gross inefficiency, when technology in common use in your organization can be leveraged, or when business goals or climate change.
Market changes or at least one significant factor that is clearly in need can be enough to trigger a process reengineering effort. More normally, higher rankings in multiple factors may lead you to attempt to reengineer one of your project (or feeding!) processes. Make sure up front that you are not changing for change sake, and that you will have enough allies and management support to finish what you start. Reengineering is definitely riskier, defining risk here as the chance to gain higher rewards or to lose your investment, in this case your clout, time, and effort. Sometimes the downside to a failed reengineering effort is that NO changes will then be addressed for a long period of time.
Reengineering a process requires a thorough 'as-is' process review, setting your goals, and a complete re-charting of all the tasks and responsibilities that are now deemed worth doing. Today, technology almost always plays a critical role in our capabilities. Many techniques we now use, or at least are familiar with, may not have been available when your process was first laid out, or even as it evolved.
Questioning each step of your process, really getting down to whether or not each step adds value to the overall process, is a painstaking process in itself. Ask yourself when deciding to reengineer, whether your team has the knowledge, the time, and the patience to walk through all the steps one by one, probably with multiple groups multiple times. While your group may have something to gain, another group may end up feeling like they lost, whether it be people or control. Remember, just because you have an AH HA moment and realize where great savings can be had, your associates may well take some hard convincing, over a period of time. Reengineer (at your peril...) when you see huge gains from cutting or crafting many steps, when your change may make the difference between success and failure, or when adopting a new technology will allow you to leapfrog your current, out of date, processes.
Watch for Part 2 of this article in next week's Business Analyst Times
Don't forget to leave your comments below
Darrel Raynor is a Principal Consultant at Advanced Management Services, Inc. (AMS), a full service management consultancy servicing a global client base. Darrel Raynor is a senior technology executive, consultant, and turnaround specialist with over twenty years of leadership experience streamlining operations, systems, people, and projects. Darrel increases margin and profit, and decreases organization friction internally and externally with customers, vendors, and partners. Problem solving, process improvement, and operations optimization are his passion. For more information, visit www.amsconsulting.com.
© Advanced Management Services, Inc
Team Training For Successful Projects: Use A Skills Matrix For Planning!
Published in: American Programmer, premier journal of software engineering
Datamation, international large systems journal
Datamation Europe, international large systems journal
Interact, journal of Hewlett-Packard computers
Technology in Business, newsletter
- IEEE Standards Collection, Software Engineering especially IEEE Std 830-1993 IEEE
Recommended Practices for Requirements Specifications.
- http://www.apu.edu/~bmccarty/curricula/cs524/srd.html Azusa Pacific University,
Department of Computer Science, CS 524 Software Engineering I is a good, beginning outline for Requirements.
- A Guide to the PMBOK - Project Management Institute www.pmi.org