You don’t often hear terms like “requirements” when discussing Agile Development – but understanding the needs of the user and sponsor is critical. We can help you plan and execute effective sprints and releases, and manage user stories on the go!
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.
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.
A program to improve the organization’s capability to develop and manage requirements in support of application development and other business initiatives.
A program to move an organization up a maturity ladder of requirements capabilities in the following areas:
Practices and Techniques
Deliverables / Results
Building the Business Case
Generic statements concerning the value of good requirements will not be sufficient to support spending time, budget, and resources on a program to transform requirements in your organization. Whenever resources such as money or effort are consumed, a clear explanation of rationale is needed in business terms indicating quantifiable benefits.
It is always necessary to clearly explain the timeline and return on investment (ROI) that requirements improvement provides. Ongoing executive support is crucial for the success of a requirements transformation program.
Use the Maturity Model as a framework for improvement
Be forward looking, not backward looking
Positive in reasoning, not negative
Simple arguments get funded while complexity just confuses
Be sensible about what can realistically be accomplished
Spend your time asking good questions
Get the hard facts: Include industry studies such as the CHAOS and BA Benchmark Reports
Talk implication, not problem or need
Baseline Your Level of Requirements Management Maturity
To understand the relative strengths and weaknesses of the organization across multiple capability areas
To set a quantifiable baseline measurement to measure subsequent improvement against
To serve as a reference for directing requirements improvement on a targeted basis to best suit your organization
Creating a Requirements Practice Improvement Plan
To serve as a communication vehicle to the change process
To provide a common understanding to the organization of the tasks and target objectives of the change process
To serve as a reference for tracking progress against objectives
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 deliver the data.
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.