Articles, tools, and resources from The Requirements Experts. For information on our services visit www.iag.biz. We want to hear from you! P - 1 800 209 3616 E - [email protected] var sc_project=6429084; var sc_invisible=1; var sc_security="7d3c35c0";
How Necessary is Requirements Definition for that Small App or Enhancement?
Small application development projects are lighter and usually don't require such extensive process standards, advanced methods, governance, documentation, planning and management that larger IT projects do.
But don't make the mistake of skipping the requirements altogether!
Start by quickly identifying the high-level objectives, the boundary or scope, and developing a basic plan for requirements elicitation. Then facilitate the requirements discovery sessions with the key subject matter experts. It may take a number of meetings over a few days - or even one or sometimes two weeks -- but the interactive, facilitated sessions are essential. At IAG, we also recommend a paired-analyst approach to the elicitation, analysis, reviews and documentation. This enables higher quality requirements definition and faster turnaround with real-time modeling during the sessions.
On these shorter and smaller projects it's about following a light process with efficient and effective techniques, using experienced analysts/architects with the right tools and producing just enough requirements detail that will be necessary and sufficient to meet the project and app dev objectives.
Midnight is a dark time, like a looming deadline which you're pretty sure you can't meet. No one is ever sure exactly how they got into the position of running up against midnight, but it usually means long hours late at night - and lots of caffeine. Perhaps it also includes a dose of wistful thinking and wondering about the project plan that seems to be growing like David Banner in a snit. Sometimes it happens, the work load just got misjudged, or the magic of juggling priorities and fate landed a few choice lemons in your lap. Maybe it's a different problem altogether.
I've noticed lots of analysts have trouble with estimating the amount of time it will take to complete business analysis and the elicitation and documentation of requirements for a project. I remember evaluating a team where the most forgiving management stakeholder I interviewed stated they were currently at 300% of the expected time needed to get requirements - and that was just her personal time... not elapsed time (which was months over schedule). Estimating analyst effort is tough because business analysis is inherently about taking a concept that is airy-fairy-fluffy, and turning it into something that is concrete-with-dimension. Here are some ideas to think about late at night - hopefully some of these will prevent you from burning the midnight oil on your next project.
Your company might be lousy at scoping... It's crazy the number of companies that don't stick a little micro-engagement on the front end of their analyst work effort. The only purpose of the engagement is to figure out how long (with reasonable precision) it will take to do requirements, and to figure out the plan to get these requirements done. Sound silly - a plan to do the plan? On the contrary, it will likely end up as the highest value you offer as an analyst organization. Remember, many companies also spin for months on very early stage projects with little to show for it - this micro-engagement will break that spin cycle. The other added bonus is that high quality requirements plans keep stakeholders engaged, and that makes it more efficient for everyone.
Your company might have ambiguously defined process and outputs... This situation is like trying to shoot a bulls-eye while riding a mad bronco while shooting at a bouncing target. Hitting it ain't going to happen! In my early years, I once had an executive say at the end of an engagement, "can you get some more business context into those requirements?" I said, "we've already documented the process flow, data flow, business rules, for every process in the business and used these as the basis for the business requirements, I also have a context diagram, business objectives, and good representation of the issues and interdependencies. What's missing?" I guess he figured I had his funding plan all figured out too. Get some precision on the expected outcome and what that means before you start committing on timelines.
Lousy practices (ouch!)? OK, so this shouldn't be rocket science, but you might want to try breaking analysis down into Use Cases, Business Events, User Stories, or some other collectively-inclusive-yet-mutually-exclusive bits of work. Then estimate how many of these you have. Start with the business process areas, how many big processes are we dealing with, how many Use Cases in those processes, etc? Here's the magic bit... keep track of how long it takes you to do one for you and other members of your team.
Maybe it's the review process that needs improvement? Some review processes have very little end in sight. Especially ugly is the organization that expects to get business signoff on very detailed systems specification with lots of techno-babble. I did some consulting for another company that was big on peer reviewing. Peer reviewing is great, but every reviewer at that particular company did requirements a bit different, so it was driving the analyst teams nuts and creating lots of inefficient rework. It will save you lots of time and effort if you get a clear expectation of level of detail, form, format, and maybe even get agreement from the stakeholders on what a good requirements document looks like before you get underway. At least that way, you can show the reviewers what the agreed upon target looks like - or walk recalcitrant stakeholders and sponsors through the templates that worked so well on that other successful project. Then show them how yours provides the same level of detail, and walk them through the process through which that detail was assembled.
Here's a secret - only a small minority of companies actually produce requirements plans on projects. Yet many of you end up burning the candle at both ends trying to meet a somewhat arbitrary deadline on the requirements preparation. Don't stay on a train that will keep taking you to midnight over and over. Step back; it might be time to change the process.
Small IT projects are lighter and usually don't require the comprehensive Requirements Definition & Management of the larger projects. But don't make the mistake of skipping the requirements altogether!
The Requirements Maturity Model (RMM) is a means to benchmark an organization’s effectiveness in requirements definition and management by looking at maturity in six underlying capabilities. Like similar standards-based models, it classifies companies based on observed, tangible competency in each capability to make an objective assessment of overall maturity.
How is the Requirements Maturity Model Structured?
IAG’s Requirements Maturity Model has two dimensions:
Maturity Level: IAG’s is a staged maturity model similar to those used by several industry standards bodies. An organization progresses up the ladder (to the right) as goals are achieved and thresholds surpassed. Each level of maturity shifts the emphasis to different requirement practice characteristics. Each level builds a foundation for succeeding levels.
Capability Area: Six capability areas are assessed and combined to determine the maturity level of a organization’s requirements management practice. These six are the fundamental building blocks for requirements definition and management and include:
Process: Definition, usage, and management of requirement procedures.
Practices & Techniques: Definition of how analysts will perform work, the efficiency and effectiveness of these activities.
Technology: Provision, usage, and integration of software tools in the context of the requirements practice.
Staff Competency: Level of knowledge, skills, and ability of the workforce.
Deliverables: Definition, production, and usage of work products as output from the requirement process.
Organization: Organizational model and services delivered to stakeholders, the provision of resources and resource management in the delivery of these services, and the framework of process and tool governance.
Read: The Requirements Maturity Model Explained White Paper
Overall Maturity is a composite of performance across the six capability areas. IAG weights each area slightly differently based on our experience in what drives effective long term performance and consistency in requirements execution. Hence, each respondent has “maturity” determined within each of the six capability areas, in addition to a single aggregate maturity score. Maturity is very ‘step-like’ in nature. There is no “Level 2.3” for example. An organization progresses up the ladder as tangible goals are achieved and thresholds are surpassed. From time-to-time, IAG may present more granular sub-step data to readers to assist in visualizing trends; however, our intent is to show the progression of skills that happen at Level 1, at Level 2, at Level 3 etc.
Beyond the Requirements Maturity Checkup: Requirements Management Maturity Assessment
The Requirements Maturity Checkup was created as quick and enageing look at the surface of your organization's requirements practice. For an exhaustive third-party evaluation and fully detailed view of your organization's requirements, IAG Consulting will conduct a Requirements Management Maturity Assessment (RMMA). Using interviews, testing and behavioral questionnaires, IAG prepares an analytical report which includes specifically targeted recommended actions based on the rating of your current requirements processes, staff competency, practices, techniques, tools, level of organizational support and quality of deliverables and results. Typically the research and interviews are conducted in a one-day onsite visit and the detailed report is provided to the client within one week of the engagement. Visit Requirements Management Maturity Assessment or Contact Us for more information.
Plagued with chaos? IAG will bring structure to your requirements team and transform your requirements practice so you can get it right again and again
A strong requirements transformation program will provide a huge payoff for your business. This checklist will make sure you are hitting all the right points
A BI Project can only be successful if it actually gets built and if the Clients utilize it. Data Warehouse best practices indicate that there are some enablers toward making a BI implementation successful
Have Strong Executive Management Support
With executive sponsorship and involvement all challenges can be overcome; without it the project may be doomed from the start.
Ensure there is a justifiable business value to a the data requirements
Simply put, include data in the data warehouse that can result in measurable dollar benefits to the business itself. Data with no or little anticipated benefit should not be included “just because we can”. A Business Intelligence system can be an incredibly powerful management tool, or it can be a complicated, confusing and cumbersome monster that doesn’t get used or becomes unreliable.
Have strong client buy-in / participation throughout the Project’s Life Cycle
When business users actually provide the business requirements for the BI system they develop a stronger sense of ownership. Having an understanding of the design and content results in a significant improvement in overall adoption and utilization rates of systems developed with direct user involvement.
Hold formally facilitated Requirements Discovery Sessions
Requirements Discovery Sessions facilitated by appropriately skilled analysts create an environment of open discussion that facilitates consensus for critical information requirements from the selected group of business knowledge experts.
Derive the Data Requirements from Business Usage Scenarios
The facts and measures (and related dimensions) to be included in the Business Intelligence System should be based on how the data is to be used (not merely by what data is available). This means driving out the type of management analysis needed to meet the area’s objectives and defining the measures required.
Adopt and Maintain an Evolutionary Philosophy toward the Data Warehouse
Apply the 80/20 rule. Clients will perceive benefit from a timely implementation of 80% of their total requirements. “Get it in... and Grow On”. Get real-world usable Business Information into the hands of the Sponsoring Management as soon as possible so that they receive and perceive real benefits for their development dollars.
In order for the Team to provide a Commitment they need some way of estimating the work effort of the Product Backlog Items. To help teams determine their commitment level Scrum employs a rather unique way of estimating through a technique known as ‘Planning Poker’. Basically it works like this:
1. Each Team member (except the Product Owner) is given a deck of Planning Poker cards (that carry a value of between 0 and 200).
2. The team reviews each product backlog item and decides which is the smallest / least complicated item and assigns it a value (e.g. 2-points). It really doesn’t matter what units you use (it could be popsicle sticks for all that matters) as the estimates are all relative to each other.
3. Then, starting from the top the Team selects the first item from the product backlog
4. Each team members selects a card that they feel represents the effort that will be sufficient (on average) to complete the item to the Team’s definition of done by comparing it relative to the 2-pointer.
5. Once everyone has estimated, they each turn their cards face up. The person who estimated the highest is asked to explain their reasoning. The same for the lowest. The Product Owner, while not participating in the estimation exercise is available to provide clarity, examples, explanations, and elaborations of the item being estimated.
6. This estimation process is repeated until a consensus is reached for each item as the team goes further down the list. The estimation process is time-boxed (usually 1-hour).7.
At the end the points (or popsicle sticks) are added up and allocated based on the length of sprint (e.g. 2-weeks) and by the average number of hours per day a person can devote to the sprint (e.g. 4-6 hours accounting for email, meetings, breaks). This becomes the sprint goal. The Product Owner is invited but only in the capacity of clarifying, explaining, and expanding the Product Backlog item (User Story) to assist in the estimation effort and not to provide comment on the estimates being made. The Planning Poker exercise is usually facilitated by the ScrumMaster
Good reports deliver business value. They give decision makers the information they need to take fast, effective action and save time, effort and money. There are three attributes to defining effective reports: Action, Stakeholder, Information:
Action:
A decision or task used to manage or operate the business. A Stakeholder takes Action using Information. Actions are measurable, no matter what they are called ("objectives", "goals", etc.). "Be informed" is not measurable. "Describe [situation] to executives" and "Satisfy regulators" are.
Stakeholder:
Someone, often a manager, who will take Action based on Information. Reports are created because the Stakeholder needs to make a decision or understand a problem. If you could automate the action it’s usually part of a process, not a report.
Information:
Data, aggregated and presented in a way that answers a question. Describe only the necessary data and formulae, the way the data should be structured into groups or summaries, and the best way to deliverthe data.
When Eliciting High Level Reporting Requirements Ask, in the following order:
1. “In the context of this project, what decision or task is important to running your business?” OR “What business questions do you need answered?”
2. “Which Stakeholder takes that Action?” OR “Who needs the answer to this question?”
3. “What Information does this Stakeholder need to know how to Act?” OR “What information do you need to know to answer that question?”
4. How is the information viewed?” (This is the dimension – by week, by branch, by department, etc.) Focus on the essential Information needed to guide the Action. It’s easy to start enumerating data elements andscreen layouts when you're looking for "web-based" "email" or "loudspeaker" (based on the Action and the Stakeholder).
When Defining High Level Reporting Requirements:
Fill in the attributes, starting with the most important reports, for example, reports with Actions that are critical decisions, or that have many Stakeholders using the same Information to support different Actions.
When Documenting Detailed Reporting Requirements:
Describe the Information, Stakeholders and Actions in enough detail for a report designer to start building mock-ups. At this stage you'll define delivery schedules and data sources and page layouts. Your last step is the traditional starting point for defining reports.
1. You will always be describing a process. Determine the process that is to be automated, and describe it.
2. You must understand something at one level before you can truly understand it at a lower level. Start your analysis by describing the overall process at a high level of abstraction to form the framework of the rest of your analysis.
3. You must describe "What" not "How". The business process should be described independent of how a system would help a user to complete the process.
4. Follow the “80/20 Rule”. The “80” = the main process flow, when everything goes smoothly. The “20” = the variations from the main flow.
5. Describe each step and sub-step in a process as "Somebody does something with some information". This syntax will help describe the process in a way that is understandable by all, and will lead to the simple identification of the true business requirements.
Maturity is More than Looking for Grey Hair and Wrinkles
The concept of capability maturity has been around since Deming first started the quality movement in the 1950s. So what's a "mature" business analyst? Are we really looking for grey hair and wrinkles to determine that individuals or collective organizations are consistently going to perform at a high level of quality? Is there some measure of "prune-i-ness" that you can use to pick out top performers?
I think not.
Overall, if an organization wants to change the performance level of its business analysis function, it has to focus on six underlying capabilities: processes, practices, people, technology, organization and deliverables. Sure, you can get a short term bump in productivity by being draconian, but it is simply not possible to make material, sustained change without systematically addressing these six capability areas. The question in each of the six areas is not whether you have, for example, processes or not. The question is the degree to which an organization accepts and adopts that process as the best possible way of doing things. This means that some organizations think they have a process for requirements definition and management ... but admit it's actually quite ad hoc. At the other end of the spectrum, organizations have institutionalized the process, and can describe their efforts to continuously optimize this process so that it's alignment to delivering stakeholder value is maximized. These two examples are the extremes of requirements definition and management maturity.
As an organization gets more mature (getting less ad hoc and going more institutionalized in processes, practices, skills, etc.) it radically changes its overall productivity. This productivity is a real, tangible thing you can measure. In fact, the maturity of business analysis capability dramatically reduces things like time-to-market for IT centric services, and makes little problems like over-runs and project failures start to go away. What people tend not to realize is that maturity - and the overall level of value delivered by an analyst organization - is also measurable. Maturity of requirements definition and management within organizations is a real, tangible thing - and no... it's not based on looking for grey hair on the leadership, or seeing especially wrinkly analysts.
A funny thing happens when organizations suddenly wake up realize that poor requirements are killing their business (and likely careers). CIO's think that fixing the problem of poor requirements can be solved purely by hiring smart people. I call this, "attempting to adjust the overall performance of your organization purely through the 'prune-i-ness' of your analysts". Its results are as bad as it sounds and the CIO eventually takes the fall for having such expensive people on the payroll. In fact, lower skilled people in high requirements definition and management maturity organizations will VASTLY outperform highly skilled people in low maturity organizations. Getting performance is not strictly about adding grey hair, it's about addressing the underlying issues that cause poor requirements: poor processes, lack of techniques, poor organizational support, lousy technology, incomprehensible requirements deliverables, and yes, there also might be an issue with skills.
