Tag: BABOK

Why Use a Requirements Matrix? Part 2.

Written by Cynthia Low on August 24, 2010. Posted in Articles.

Follow Up – Multi-Tasking

Click here for Part 1 of this 2 Part series

Here is a quote from one of the project oriented discussion groups I follow: “Multi-tasking, road-runner, or focused effort thinking: Most of our folks have been interrupt driven since they started working in the corporate environment. If a “fire” erupts somewhere, go put it out then start looking for the next fire in addition to doing the project work that you have been assigned. In the Critical Chain (CC)/Theory of Constraints approach, we want people to focus on one and only one task and not multi-task. When people are able to “single-task”, their efficiency and productivity on that project goes way up and CC works miracles. When people multi-task, CC suffers tremendously,” says Jack C. Randazzo, RTR Project Management, Lucent Technologies Inc.

How is training your development team related to successful projects? Time-to-market, or product cycle time, is growing in importance. Methods and tools are rapidly evolving. Project teams are continually being asked to shorten their development cycle. One of the first areas they may be asked to reduce, or even do without, is their own training. As a Quality Assurance Director and as a management and technical consultant, I have been asked to review many ‘time-challenged’ projects in the past few years.

One common factor I found among the projects I have reviewed, almost without exception, is that adequate training of the development team was not planned for or funded. Very few projects had a team training plan. When the going gets tough, developers were asked to pick up a new method or tool, or even worse, both, while working at breakneck speed on the project. This article looks at the reasons why team training is critical and how to construct and use a team training matrix.

Systems, Tools and Methods are More Complex

A common misconception among traditional MIS and non-MIS managers is that development team members can just “pick up new technologies in their spare time…” In the past, most analysts could learn using a new version of a mainframe sorting package, a new version of Microsoft DOS, or a source library system. These were relatively minor updates that built upon existing skills.

Today’s enabling technologies use radically new techniques and tools and do not come without a price. For all that control, complexity is needed. It takes only a project or two that either fails completely or misses functional and time estimates by a factor of three or four to educate managers that integrating such knowledge cannot be done “on the fly.”

Many managers are not used to planning for the systems administration and underlying control of many of the low-level functions of LAN and other Client/Server systems. One of my traditional estimates of the likelihood of a project’s success was that it only addressed one area of technological change. Changing more than one of the database, operating system, methodology, development tools, languages, or platform along with major functional updates was risky, to say the least. Changing more than two at a time almost guaranteed failure or frequent scaling back of project goals. Today, however, projects are cropping up everywhere that change ALL of the above at once! No wonder there is chaos in application development. Your project team will need in-depth training in each new area.

Estimate Your Training Needs

Identify the skills your team needs for the project. My rule of thumb for methods and supporting development tools training averages tool vendor, third-party training vendor, and my experience:

Ask the vendor for a plan to bring your team up to speed
Ask a third-party training firm that you trust for the same
Add the vendor’s and training firm’s estimates
Add in your gut feel for the least amount you can get away with
Divide the total by 3: this is the least amount you should plan for!

For example, if your tool or method vendor recommends 12 days per developer to really learn to get the best of their wares, the training firm recommends eight days, and your best guess is five days, total these. Take your total of 25 and divide by three, giving 8 1/3 days. You now have created somewhat realistic training estimates.

Don’t divulge your formulae, or your management is guaranteed to hold you to your five day estimate, and very well may ask for a reduction. Fight for the full 8 1/3 training days in your project planning sessions! Make sure you cover all the days when the vendor or the training firm and your people can devote 100% of their time to training. Offsite is best, although working in a known environment can help direct attention to the areas that need tuning or other support.

Build Your Project Skills Matrix

Constructing and using a project skills matrix will pay back many times the effort expended. The matrix will have three areas of skills to review: application, technical, and team. To get started, meet with your internal or external customer to review any application-level skills needed. Twice in the recent past, I have had customers volunteer to help train a team, once at no cost! They may welcome your team’s learning more about their business. Your needed vertical skill areas may be financial, distribution, manufacturing, engineering, or a combination of these.

Next, meet with your system architects, technical planners, and technicians that have recently completed a similar project, whether in-house or for another development shop. Contractor programmers and consultants can be invaluable, especially if this is your first foray into a new technical realm. Identify all areas of technical skills that need to be added to or refreshed. Do not forget to list the skills needed to plan and execute a system conversion if you are replacing an existing system.

Finally, meet with all the managers that had any of your team members for their last project. Review each person’s strengths in terms of how they relate and help lead the team, how they handle stress, changes to schedules and project content, and how they may best contribute to your project. Ask if they think training in leadership and teamwork would help them work at a higher level. Make sure you list the ‘soft’ skills your project will require, such as interviewing, prototyping, managing multiple teams, as well as estimating and managing the project plan. Areas frequently overlooked are how to run a meeting, how to gel as a team, accurately figuring and reporting project status, and many times even how to manage a project.

List all the pertinent technical, application, and ‘soft’ skills on one axis of your matrix. Order them by when they will be needed in the project. For example, if you are doing up-front paper-based usability testing, make sure you schedule interviewing and prototyping training early on. If you are doing usability testing with unit tested modules, those skills can wait until just before system test.

List your team members on the other axis. To have maximum flexibility, add four more columns: users, borrowed resources, consultants, and contractor programmers. You may be able to fill in for lacking skill categories by using an expert for a limited time. If you plan to use these outside resources, try not to schedule them for more than four hours per day project work. You will need the rest of their time to mentor your staff.

Now, being as objective as you can, choose a highlighter color for expert, one for skilled, and one for familiar. Highlight the skills you need to have experts, those you need skilled people, and those you can get by with passing knowledge in their respective colors. You may now want to reorder the matrix to show those skills that are crucial to project success at the top, keeping them in order of when you will need them, working down to the nice-to-haves.

To complete your matrix, distribute it to your entire team including consultants and contract programmers, the project sponsor, and any of your peers or managers that show an interest. Use a legend or key to show that you need four skill levels: expert, skilled, familiar, and completely lacking. One way to fill in the blanks is to meet individually with each team member. Another way is to meet team by team in groups of up to ten. A bonus for meeting in teams is that you can brainstorm ways to fill in your project needs. Make sure your team knows that they will be held accountable for their skill level estimates and assigned deadlines accordingly. This tactic may help reduce the optimistic ‘skill creep’ that many resumes have.

Many times management will review and approve a carefully thought out training plan where they will not approve your gut feel. Include your methodology, the risks to the project of not training adequately, and the estimated costs to complete your training plan. Offer several alternatives, with project schedules and costs increased to accommodate lack of training. Use your four extra columns to add flexibility to dates and costs by involving more users, borrowed resources, consultants, and contract programmers. Many times having mentors available, as long as they are not 100% scheduled, will allow you to reduce your training.

While no guarantee of success, my experience is that projects that use a skills matrix have less frustration and tend to be more controlled throughout their life. I am sold on the process of constructing and using a skills matrix. I am working on a Lotus Notes version that I will release to the public domain if there is sufficient interest.

Side Benefits of Training Planning

Training planning sessions highlight the level of experience each of your team has in particular areas. Reviewing their prior training familiarizes you with their interests as well as their proven skills. You may run across someone with unexpected prior experience in an important area. At the least you will have valuable information for input to decisions such as whether to train the whole team on certain tools or set aside ‘specialist’ time for crucial areas.

Planning for training will keep the ‘flail’ time and needless experimenting to a minimum. It also allows you to do ‘Just in Time Training’. People remember their training best when they begin to use it immediately. Many people forget quickly that which they do not practice.

Training planning helps you negotiate with tool and training vendors. When you can spell out exactly what your needs are for the project, you are more likely to be able to price and close a package deal. Don’t overlook points such as free seats for a vendor’s public classes, free passes to annual user group conferences, and documenting your experiences as a ‘success story’ for their marketing efforts.

In evaluating project managers, how well their people were prepared for their tasks can be a critical measure. It can indicate how important increasing their people’s skills is to a manager. We all know that meeting your dates with a quality product is paramount. Holding the interests and loyalty of team members by not asking them to do the impossible will increase the likelihood of your next project being successful.

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

Resources

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 especially Project Scope Management 5.3, Scope Definition.

Seven Success Factors for Requirements Planning

Written by Elizabeth Larson on July 6, 2010. Posted in Articles.

If care isn’t given to planning the activities of defining product requirements, the entire project could go awry. It is one of the biggest reasons why 60% of project defects are due to requirements and almost half of the project budget is spent reworking requirements defects.[¹] There are many success factors that can relate to projects, products, and processes. Some apply to all three. For example, time taken to clarify roles and responsibilities helps ensure that all stakeholders know their accountabilities. Without a clear definition, it is almost certain that not only will tasks remain undone, but that those involved will be unhappy. Since stakeholders are involved in projects, in defining product requirements, in implementing new products, and in completing business processes, defining roles and responsibilities applies to all.

Here are some other examples of common success factors:

Collaboration
Regardless of whether we are working on projects, products, or processes, we work with other people. Collaborating, establishing partnerships, and using our networks in and outside of our organization help us face challenges and problems when they arise. We’ll find that others are more willing to help us through difficulties. When we implement a new project, product, or process, it is important to obtain agreement from those affected. Without this buy-in, the affected stakeholders may sabotage our efforts, intentionally or unintentionally.
Clearly Articulated Benefits
All stakeholders involved need to have a clear understanding of what they are trying to accomplish and why. They need a clear sense of direction, and also an understanding of how their work contributes to the health and well-being of the organization.
Managed Scope
Scope applies to projects, product requirements, and processes. The project and product scope are intertwined, since the scope of the product requirements affects the scope of the project. The project scope includes the entire effort to produce and implement the end product. Developing a prototype of a new bridge (product), for example, will usually take less effort (project) than creating and building the bridge itself. The scope of a process also needs to be managed. All processes begin and end, which are their boundaries or scope.
Process Scope
This intertwines with the other two types in that the relative process scope size will affect how large a project is to work on it, and the product deliverables that are produced. As an example, if the project is to create software for a retail store point of sale application, it will be larger if it includes the process of Returns in addition to just the process of New Sales transactions.
Clear Communications
Communication that sends the intended message in its entirety is meant to clarify, and if direct and unambiguous promotes success in work on projects, product requirements, and processes. Incomplete, unclear, or dishonest communications are some of the easiest ways to ensure conflict, as stakeholders struggle to make sense of what information they have received.
Asking the Right Questions
Whether working on projects, product requirements, or processes, we will encounter things that need clarification. When we don’t understand such things as a requirement, a task, or a process step, we know to ask for clarification. However, sometimes we assume that the sender and receiver of the message have a common understanding when, in fact, they do not. We call this having different “mental models,” or mind pictures. On product definition, for example, a common reason requirements change is because we think we understand the business need, when really our mental picture is quite different from our clients.’ Because differing mental models can cause a great deal of rework on projects, products, and processes, it is important to ask clarifying questions.
Adequate but not Burdensome Documentation.
No matter how good our memories are, we sometimes forget important things.
- Project. Agreements, deliverables, milestones, and risks plans are required on projects of all sizes.
- Product. A list of requirements and/or appropriate models, plus a method for ensuring that approved requirements have been implemented, are important for most business analysis work. Although the amount of formality varies from project to project, the need for the appropriate amount of documentation exists.
- Process. The documented process of who performs the work, what steps they will take, where the process begins and ends, initial inputs, and final outputs are included in the process documentation that is needed to ensure repeatability. Of course, too much documentation can be demoralizing and costly.

Common Success Factors for Projects, Products, and Processes – Seven “Cs”

Clarify roles and responsibilities
Collaboration
Clearly articulated benefits
Crisp and managed scope
Clear communications
Crucial questions
Critical documentation: adequate, not burdensome.

In summary, projects can easily struggle and fail for many reasons. Not taking care of requirements and failing to plan are major contributors to failed projects. By following our seven “Cs” of planning, you can help your projects achieve greater success, run smoother, and result in happier customers. The success factors apply equally to other facets of work, such as with project and product planning, and will help beyond requirements planning.

The preceding is an excerpt from the book Practitioner’s Guide to Requirements Management, Part I: Requirements Planning, written by the authors of this article.

Don’t forget to leave your comments below

Elizabeth Larson, CBAP, PMP, CSM, and Richard Larson, CBAP, PMP, are Co-Principals of Watermark Learning (www.watermarklearning.com) For over 20 years, they have used their extensive experience in both business analysis and project management to help thousands of BA and PM practitioners develop new skills. They have helped build Watermark’s training into a unique combination of industry best practices, an engaging format, and a practical approach. Watermark Learning students immediately learn the real-world skills necessary to produce enduring results. Both Elizabeth and Richard are among the world’s first Certified Business Analysis Professionals (CBAP) through the International Institute of Business Analysis (IIBA) and are contributors to the IIBA Business Analysis Body of Knowledge (BABOK). They are also certified Project Management Professionals (PMP) and are contributors to the section on collecting requirements in the 4th edition of the Project Management Body of Knowledge (PMBOK). Their book, Practitioner’s Guide to Requirements Management, Part I: Requirements Planning is available through Amazon.com. For more information, contact them at 800-646-9362, or at www.WatermarkLearning.com.

[1] Software Engineering Institute (SEI’s) Square Project updated 5/12/05.

Breaking Down the Silos for Better Requirements Elicitation

Written by Paul Mulvey on March 23, 2010. Posted in Articles. 1 Comment on Breaking Down the Silos for Better Requirements Elicitation

I’m sure that by now we have all seen statistics about the reason that X% of projects fail is due to requirements. They always point back to the fact that the BAs did not capture the correct requirements. Well, maybe, just maybe, it isn’t our fault. It may be the way in which our companies are set up that force us to miss requirements. Yes, I said it; the way in which our companies are set up may cause us to miss requirements. But now that it has been said, we can no longer use it as an excuse. We need to understand how our companies are set up so that we can overcome those obstacles and become more effective. If we work within product silos, we need to understand how to overcome these silos in order to develop an effective business process. First, we need to travel back in time to understand the foundational architectural principles.

A History Lesson

In order to understand the silos concept, let’s start by going back to Greece. The ancient Greeks, when not competing in the Olympics or writing epic poems about Odysseus, built temples. Imagine yourself as a temple worker assigned to column duty, we’ll call it column A. It was your job to understand the dimensions of Column A, what the column should look like, height and width, etc. Basically, you were a BA working within Column A and Column A only. Occasionally, you would interact with those working on Column B or C over lunch or something, and you would learn what they were doing. But, basically, you stayed within the confines of your own column and you made a great column. But there were business analysts back then that were assigned the responsibility of the Architrave. In architecture, the Architrave is the ornamental band that rests on top of the columns (sometimes called a lintel). If the BA working on the architrave did not coordinate all the efforts of the individual column makers, it would not work properly, or rest properly across the columns.

Figure 1.Greek temple façade showing “silos”

Many companies today are organized in very much the same way, but replacing the physical columns with product silos. We have built our product lines into neat, organizational silos (the columns from the temple), and the analysis work is performed within these silos. Since authority and control from the top of the column only extends to the bottom of the silo, analysis does not normally occur outside of the column, or silo. What happens is that when the Architrave project comes along, no one silo wants to take ownership of the work required to analyze it because it is not in their “column authority.” The result is that the business process that crosses over the silos is not fully analyzed because no one examined something that went across the silos. A manager in silo A controls the activities (and probably budget) within the silo and is reluctant to allow one of his analysts to go outside of the silo. The reluctance may come from budget concerns (“If I’m paying for the analyst, I’m accountable budgetary-wise for the work that analyst performs”), it may come from control (“This is my department and my analysts only work on my projects”), or it may come from organizational policies (“No analysts may perform work outside of their department”). However it occurs, it hurts the project because the overall business process that needed to be analyzed was not analyzed.

Let’s create a hypothetical example of how this happens. Imagine a grocery store with product lines (or silos) of Marketing, Retail, Sales, and Distribution. A corporate sponsor comes up with a great idea to have customers order groceries over the internet. Since it was initially pitched as a Marketing idea, a Marketing BA performs a stakeholder analysis and determines that Marketing need to update the store’s website, and Distribution needs to deliver the product. So Marketing goes off and starts collecting their requirements, and Distribution does the same. But the Distribution BA uncovers that Marketing has no plan to sell the product, so Sales should be contacted for their input. Now Sales is involved, but they are off creating their sales requirements, and not involved with Distribution or the website. The head of Retail hears about this project, and wants his silo to be involved because there could be an option for customers to pick up their ordered groceries at the closest retail store and thus drive business to his retail sector. So now there are four separate efforts going on to create the requirements, but they are not talking to one another. When they all come together, the requirements do not match up, as each person understood the effort from a different perspective (e.g. they were all concentrating on their individual column). The end result is that it’s a mess, and there are probably cost overruns, unsatisfied sponsors, and the business loses a lot of potential sales if their competitors are able to beat them to this particular idea.

Look at the Business from the Architrave’s Perspective.

The Architrave has the advantage of sitting across all of the columns. To do so, it needs to have a lot of information about each column: it needs to know how much weight each column can hold (or manage), it needs to know the design of each column, to keep that design going into the architrave, and it needs to span across all the columns. It also has a viewpoint above the columns, so it is able to see the “big picture.” Before you can even go into understanding the business process, you need to determine exactly what business processes that you are going to discuss. Since you are at the top, think of processes that you would have to perform as part of this Web-ordering idea. There are probably more, but within 10 seconds, you can probably come up with, “Sell new service”, “Promote new service”, “Order product”, “Purchase product”, “Distribute product” and so on. Look at all of these from a process-perspective, not a “which silo owns it?’ perspective.

Figure 2. Business processes represented across business silos

By looking at it from a business process level, we can see that the process goes across silos for several of these processes, and we begin to see how they work across the entire organization, not just in one silo. For instance, with “Promote new service,” we might just think that it is a Marketing function, or a Sales function. But when the analysis is done across silos, we are able to understand that the real intent of the sponsor is to combine the promotion with the Retail function so that they can coordinate the promotion. If analysts did not study the business process from a point-of-view of the business process, the coordination with the Retail channel would have been lost. Also, it may be that in studying the promotion process, the analysts discover more groups that become stakeholders: Legal, to negotiate contracts for Radio and TV ad spots; or the Customer Call Center, to understand the new service and be able to explain it to customers when they phone with questions. You will likely find more stakeholders as you analyze the entire process, instead of just looking at it from your own silo’s perspective.

Completing the Temple

Alas, while it’s great to perform the process analysis at the Architrave level, one needs to have the support of the columns in order to hold it up. A process cannot survive on its own without the foundational support of the silos. Eventually, the weight of the Architrave has to be supported by the columns. This is where the business process falls into the silos. After developing the business process, then you can start developing solutions to support the business process. By looking at the process as a whole, and from above all the silos, it becomes easier to determine exactly what needs to occur to support the process, and to assign the functionally to each silo as necessary. Also, since the entire process is documented, analysts do not get caught in the trap of having each silo assume that another one is going to complete work X or work Y. Black boxes may still be around, but going into the solution, the silos know which one is tasked with supporting that piece of the process.

Hopefully, you have a better understanding about the necessity to understand how the business operates throughout the business, not just in a single silo. Not only will you have a better documented business process, more well-defined stakeholders, but you will also experience better coordination across the silos when it comes time to develop the solution. I would like to explain more about Greek culture and mythology, but I have to run, I’m lashed to the mast of my ship, and I hear the sirens calling me…

Don’t forget to leave your comments below

Paul Mulvey is a Lead Business Systems Analyst at UPS. He grew up with a Humanities professor father who would probably be very proud to know that his son has still retained knowledge of the Greek civilization. He can be reached at [email protected]

The State of Requirements Management

Written by John Simpson on December 15, 2009. Posted in Articles.

Goodbye 2009, Hello 2010!

For many organizations, 2009 simply can’t end fast enough. The brutal economy made for a tough year, there’s no denying that. However, taking a moment to reflect on things from a business analyst’s point of view, I believe there are a few bright spots to celebrate. Consider them the signs of hope for a better 2010. In this article, I want to highlight three trends we first saw emerge from The State of Requirements Management Report we published back in June 2008 on the challenges, trends and solutions happening in software product development. In that report we surveyed 200 organizations and explored topics such as:

What are the biggest challenges in innovation that companies face?
Is the Agile process over-hyped?
How does collaboration apply to requirements management?
What frustrates people more – scope creep, unrealistic expectations or lack of testing?
Which genre of music is most popular? OK, that one we threw in just for fun.

I never anticipated the kind of response that report would get, with over 18,000 downloads of it since we first published it, but in hindsight I think it struck a chord with people, especially those in the business analyst community, shedding light on some of the challenges we all deal with day in, day out. You can read the full report and compare the results to what you experienced this year. I would be curious to hear your thoughts and experiences. http://www.jamasoftware.com/media/documents/State_of_Requirements_Management_2008_Jama.pdf

As I look back on 2009, the three positive trends I saw emerge which will carry over into 2010 include:

1. Greater Respect and Appreciation for the Business Analyst Role

Understanding what the customers need and documenting all the requirements isn’t easy. In fact, these were the top challenges based on feedback we saw within The State of Requirements Management Report at 65% each.

As it becomes more apparent to executives and senior management that requirements are the building blocks of innovation, the respect for the people whose job it is to manage requirements increases. Can you say “Christmas bonus”? And, I’m not talking fruit cake; give the BAs you love something good this year!

In all seriousness, this heightened appreciation for BAs is also reflective in its being an area of job growth, despite high unemployment rates in other sectors. Essentially, if you have strong business analyst and product management skills, you are in high demand. Feel good about that for a moment, now put down the eggnog and get back to work. You’re only as good as your latest specification, right?

2. Greater Accountability for the Requirements Shared by the Entire Team

Collaboration has been a hot trend in product development for a few years now. But, what does that really mean in terms of results? One of the lesser known benefits of better collaboration is that over time you see an increase in accountability across the entire team for getting the requirements right and building the products to spec. That’s a good thing for everyone. How often before did all the responsibility fall just on the shoulders of the business analyst or product manager to define the set of features and write gorgeous requirements that would be magically understood and implemented flawlessly by all?

Truly collaborative teams embody this shared accountability which raises the bar for everyone involved, whether it’s your job to listen to the customer and capture the requirements or interpret the detailed requirements downstream to code and ensure the functionality is right. When everyone contributes to the development of the requirements, the success rates increase dramatically.

If your team doesn’t embody this characteristic now, you might want to make it a priority in 2010, or hope for a miracle bag of requirements pixie dust from Santa. I think that’s high on the wish list right after the Wii and Twilight stuff.

3. Agile is More of a Mindset than a Development Process.

Man, there was a ton of attention given to Agile again this year. Agile conferences. Agile books. Agile processes du jour. I think I’ve contracted “Agileitis”, the rapidly, contagious disease that can be spread from the “pigs” to the “chickens” in a Scrum daily stand-up meeting… I know there’s a bad Swine flu / Bird flu whopper of a joke in there somewhere.

The key point is, Agile isn’t just a flavor of development process. It’s a core philosophy – a cultural mindset of embracing change, inviting the voice of the customer into your process throughout, and designing workable software that is continuously improving over time. Call them releases, iterations, sprints, milestones – whatever you want. The labels are less important than the outcome of the products you produce. The evolution I saw emerge in 2009, and will continue in 2010, is the concept of a “hybrid” approach where mature companies merge disciplined requirements management practices for proper planning and requirements documentation, with the freedom for developers and testers to adopt more agile, lightweight methods to build and test new releases. It’s the best of both worlds.

I’ve seen many companies be successful with a hybrid process, and one of the reasons it’s more prevalent now is that the tools available today are designed to flex to support whatever process or processes work for your team.

Big picture – the goals are the same – build great products faster, cheaper and with higher quality. My recommended New Year’s Resolution: Adopt whatever mix of processes, people and tools you need to achieve your goals, demand and accept nothing less, and you’ll have a great 2010.

Looking ahead to January – Share Your Voice.

In January, I’ll be conducting the 2010 State of Requirements Management Survey and would love your participation. That way, we can establish an annual benchmark study for our industry on what’s real and what’s hype, and see what others are doing to be more successful managing requirements. So look for that after the holidays.

On a personal note, from my family to yours – I’d like to wish everyone and their families – happy holidays and best wishes for a prosperous new year! See you in 2010.

Don’t forget to leave your comments below

John Simpson is director of customer outreach and marketing at Jama Software. John represents the voice of the customer in Jama’s product strategy and communications. He has over 12 years experience working at software technology companies including Microsoft, WebTrends and Omniture. In his spare time, he chases his three kids around and raises awareness for cancer research in his local community, Portland, OR. You can reach John at http://www.jamasoftware.com or follow him on Twitter at http://www.twitter.com/jamasoftware.

Top Ten Reasons You REALLY Do Need a Requirements Document

Written by David De Witt on October 27, 2009. Posted in Articles.

I had the opportunity recently to write a tongue-in-cheek piece with the not-so-brief title Top Ten Reasons You Don’t Need a Requirements Document when upgrading software. At the conclusion of that article, I offered to provide a realistic counter-point — my list of ten reasons why you MUST have a requirements document in hand before you invest money in upgrading or purchasing software.

With all due respect to another and far better known David who offers his top ten lists much more frequently, here are my top ten reasons that creating a requirements document is in your best interests — and your organization’s:

1. Requirements are not features. You simply must know what your users must have to do their jobs. Distinguish thoughtfully and carefully between what is needed and what the vendor is offering. At the same time, you must be able to factor into the requirements documentation other considerations, such as budget limitations and regulatory constraints. You will need to train your users how to specify their requirements, which takes tact, training, and patience. A request usually starts with: “All I really need is..” and then wanders away. A vague or ambiguous statement — regardless of its intent — will consume user time, IT time and cause some other loss, such as the opportunity to do another project. This issue is methodology neutral: Agile methods will have the same problem if user time is not focused and users are not trained. You cannot fulfill the requirements until they’re precise and complete and you understand why they’re important to the business.

Features are not requirements. Eliminate decisions made by squeaky wheels — sometimes referred to as “design by whine” — where the loudest department gets the most resources. Your goal is to make certain that business decisions made with regard to requirements (and their associated expenditures) will generate the return you’re expecting. Start by working backward, to match the problems solved with existing software to identify the problems that must be and can be solved only with new software. Don’t lose anything you have now that is essential to the business; it’s easy to forget “hidden” requirements that oftentimes are taken for granted or ignored.
Work with your resources and manage with discipline. Developing an effective requirements document costs money and managing resources requires discipline. A politically expedient decision, even if it’s cost effective in the short run but is not the right decision in the long run, will cost time and money – eventually. From a strategic point of view, ask if the requirements process itself is going to cost more than it’s worth. You will find that using the enterprise requirements documentation process will help you avoid useless meetings, which saves time and money, but more about that later. When the appropriate constituents are communicating with each other, they accept the value of their participation because they can track the project’s payback to the entire organization.
On-going documentation is essential. It’s necessary that you continue to manage your requirements, because sometimes internal departments continue to push for a project application or feature that was denied in the last upgrade or purchase. Perhaps it wasn’t worth the cost, or its payback wasn’t acceptable to the enterprise as a whole. By maintaining continuity in your requirements documentation, you can see why a prior request was denied. If the reason hasn’t changed, it’s likely there is no need to investigate it again — and you can avoid bringing in a “new” solution to solve an equally “new” problem. Referencing prior documentation also can help you eliminate ongoing costs for applications and hardware that are no longer used.
Identify and understand the workarounds and desk drawer systems. You need to understand what in your current application made a workaround or desk drawer system an attractive solution. Then, make certain the upgrade eliminates these systems and their causes, with this caveat: You might learn, in the course of such an investigation, that a certain desk drawer system has a unique function or user, and that it’s best left alone.
Focus your users’ attention. You want to learn from them what can be done better, faster or more efficiently, but realize that users don’t always know their current business needs. In fact, users at different levels of an organization have different perceptions of business needs, priority and urgency. They tend to segregate by department or management level, dismissing problems because “it’s not an IT issue.” However, an effective requirements document requires integration and impact analysis for all departments. Know, too, that the needs of other stakeholders (senior management, operations personnel and human resources, for example) must be considered. User frustration comes from asking for one thing, and receiving another; help them articulate their needs carefully and fully. When what a user asks for is not possible, feasible or within budget, say so, because unmet expectations foster dissatisfaction. Always ask, what’s the relative value of a new “requirement” to avoid spending $10 to save a dime?. And don’t forget: users take what they have for granted, so make sure it’s carried forward in the new request.
Benefit from “outside” expertise. An objective outsider, can, will and should ask the questions an insider cannot. What works? What doesn’t? What frequent requests create problems because they’re difficult to meet with the existing application? That’s the outsider’s function; to have no vested interest in how the problem is solved. It’s a common pitfall in requirements documentation to describe a problem in terms of its supposed solution, which might not be the best, or most cost effective, approach. An outsider also can provide useful guidance on how to handle regulatory requirements that affect information systems but that most business people are not aware of, such as the prohibition against retail businesses retaining credit card numbers after a transaction.
Consider your upgrade as an investment and apply metrics to it. A comprehensive requirements document will help you decide if the benefits of the new application or upgrade justify the cost. How much more productive can the organization be with the upgrade, compared to the current application? Track paybacks for projects and information assets to determine when to re-invest or stop further investment. It’s possible that an application was a good investment — at the time. When it was installed, perhaps it saved every one of your 5,000 clerks 30 minutes a day. But today, you have five clerks and it saves them three minutes a day. That feature probably isn’t worth the cost. And some stand-alone features — such as desktop publishing — aren’t needed now, thanks to the tools available in word processing applications.
Save time. Reduce rework by spending time in the requirements gathering and analysis process, where it’s much cheaper to eliminate a “need” than realizing it costs too much (or isn’t cost effective) downstream in the design, development or application stage. Time invested in the initial steps of the process provides more time for decision making at the right time. More control of the process will help keep it moving; participants will know what to expect as you move from blue sky thinking to brainstorming to understanding to decision making. Tracking the results of your meetings will document what you’ve agreed to do and what you’ve agreed not to do and who made the decision.
Save money. To start, you will eliminate ongoing costs for applications and hardware that your requirements information gathering tells you are used no longer. With the right subject matter experts and decision makers involved at the right time, you will not be able to move forward on ideas that sound promising but contain potentially expensive problems that would have to be solved later in the process, and at a greater cost. You will open many avenues to managing costs, whether it’s eliminating unnecessary systems, consolidating a value-added system or evaluating long-term versus short-term value. You might learn, for example, that in the year required to acquire and install a new system the opportunity to use it will disappear. One of the most promising benefits of developing enterprise requirements is the strong possibility you will establish standard solutions to many of your seemingly “unique” problems, obviating the need for custom solutions. And that can be a real time and money saver.

Posted on Dr. Dobb’s Journal at www.ddj.com/codetalk and available at www.nuevista.com

Don’t forget to leave your comments below

David De Witt is Practice Director for NueVista Group’s Enterprise Requirements Management Practice, has more than 20 years experience in organizational leadership, management consulting and Information Systems optimization. NueVista’s Enterprise Requirements Management Practice helps an organization maximize the value of its most significant investments — information technology personnel, software and hardware. David’s industry expertise includes his extensive work in supply chain and third party logistics, financial services and telecommunications. He has mentored companies in their strategic planning and management of Information Systems, leading initiatives in IS department governance, business alignment, staffing, infrastructure development and regulatory compliance support and reporting. David De Witt is an Advisor to the College of Business, Indiana State University and a Phi Beta Kappa graduate of Furman University, Greenville, SC. He earned his Master’s degree and Doctorate at Tulane University. David can be reached at [email protected].