Tag Archives: business requirements

The 3 R’s For Courageous Business Analysis and Project Management

As the Enterprise Business Architecture Practice Lead at IAG, I attended the recent Business Analyst World event this June with extreme interest. The Business Analysis industry continues to grow – with more companies hiring, and more employees getting trained and certified than ever before. However, with that is a changing and dynamic environment as BAs are barraged by new methodologies from the Agile and Lean worlds; new and more prevalent ALM and requirements authoring and management tools; role confusion with BPM, Business and Enterprise Architects; and the continued pressure from their business, project management and IT colleagues.

This theme resonated throughout the conference as the subtext of many of the talks and workshops during the week.  As I sat at round tables and seminars listening to topics like the value and career path of the BA, Business Analysts were definitely vocal. I heard one participant say, “Between Management and PMs, I can’t do the job I was hired to do. Whether it’s by cutting my time short – or not getting access to the right people, I know I am not doing the job properly and it’s making me cringe handing off **** to the development team.” The frustration was clear. More than ever, they want to be value add players in the game. A game they feel is rigged against them.

Then there were the stats quoted all week long:

  • 68% of projects fail due to poor requirements (from the often quoted Chaos Report)
  • 45% of features put into production are unused (also from the Standish Group)
  • 40-50% of budget is consumed by rework (Boehm and Basili)
  • 75-85% root cause of rework is from poor requirements (from Dean Leffingwell)

Ouch. To the BA’s at the conference, this was taken as a personal attack. These stats used to be quoted to management to reinforce the importance of needing good requirements. To an audience of BA’s, this is now (quite falsely in my opinion) coming across more like a condemnation of poor work. I don’t truly believe that BA’s are perceived as the bane of every failed technology project, but it had that feeling.  And what made this even stranger was the feeling that they are being locked out of Agile projects – but still being generally accountable for solutions meeting the business needs.

With 6.2 trillion dollars being spent globally on technology projects what does this mean for the Business Analyst? Given the cost of substandard requirements, which according to the BA Benchmark could be north of two trillion dollars, the business case for the Business Analyst should be obvious. To support this, the DOL and one leading staffing firm predict a shortage of BA’s in 2013 and continued shortfall in supply as technology needs ramp up into 2020.

From the seminars I attended at the Business Analyst and Project Management World conference, one concept struck a chord for me – as advice for the Business Analyst and Project Manager – and a critical factor for application development success:

Have the courage to do the right thing.

Given whatever your role and responsibility is, have the confidence to do or say what you think is right even when others disagree.  Confronted with challenges and obstacles from peers and other stakeholders, stand resolute. Faced with uncertainly and confusion in your responsibilities in an Agile environment, create your value. Take responsibility. Learn and adapt. And stand by your convictions that good requirements and analysis are absolute.

Three R’s

As BAs and PMs, get the right information, the right training and right tools.

As Managers, help enable Business Analysts and PMs to do their job. Give them the right information, the right training and the right tools to do a good job.

For Business Analysts, remember these 3 R’s as your value add:

  1. The Right Plan: Work to a requirements management plan that defines the right approach, milestones, deliverables, tools, techniques and work plan.
  2. The Right methodology. Be adaptive and fit for purpose – ensuring the approach is appropriate, utilizes best practice and the principles of good requirements, analysis and architecture are maintained.
  3. The Right Requirements. Ensured by verification, validation, prioritization, review and traceability best practices.

And for Project Managers, the Right Stuff entails:

  1. Right alignment. All stakeholders agreeing on objectives, scope, requirements and solution
  2. Right resources. For all activities, but especially utilizing the right SMEs at the right levels that can provide expertise and decisions
    1. A strategy guy for the high level
    2. Control person for oversight
    3. And an execution person for process
    4. Right time frame. In the case of the initiation and planning phases, that there is enough time to do these critical phases just right.

Doing the right thing is hard. Doing the wrong thing is easy.

Have the courage to do the “right thing”!  Positioned in the “right way” to do the “right job”

– Judith Oja-Gillam

Track IPhone unique and for this reason can you track an iphone without special. I think that information interesting. Remember that. Also you will have no problems.

“Why Do I Need Requirements? I’m Buying a Package!”

In the wide world of information systems, development of new software receives the most attention from industry writers. Whether it is traditional magazine articles and books, or blog posts, or discussions in groups on LinkedIn and other sites, it is all about “green field” development.

However, when one considers the wider view of organizations concerning information systems, it is common that new software development is not always the primary means of implementing new systems. Organizations do need software for many different functions and data, but a lot of those are common; organizations that realize this do not develop their own software for common needs, they buy it.  It actually started a few decades ago with functions like general ledger accounting and human resources, then it moved into more specific domains like insurance or banking, and on into cross-domain ERP packages popularized by major vendors.

When organizations first started to buy more than build, they were often delighted by the time savings: “I can have it now? And not wait 2 years for it to be developed in-house? Where do I sign?” What many organizations did not realize, and their internal IT people probably didn’t see either (at first), was that it was only the pure development and system testing activities that were being saved. There was still the need to determine what the package was actually going to do. While software apps provide many common and standard functions, which ones are implemented, and how they are configured still vary significantly based on an organization’s own needs. Ahead of that, the decision has to be made concerning which package to buy in the first place. 

This is where business requirements come in. Again, the focus and discussions about requirements these days is primarily about their role in new software development, such that some organizations forget or discount the need for requirements when buying packages… This is a recipe for disaster. 

It is true that companies buy things all the time, and often use a standard Request for Proposal (RFP) process. A common process is a good thing, and proposals for quantifiable products such as hardware or components can be straightforward. An RFP for software, however, is specifying an intangible thing that has to perform a function in a specific way. That means defining complete and correct business requirements. 

A web search on RFPs or package implementation failures will quickly identify a primary cause; “Failure to clearly define the business requirements for the project”. (see http://www.orionsecuritysolutions.com/the-o/item/188-request-for-proposal-mistakes).  

Even the (in)famous lawsuit between Waste Management Inc. and SAP concerning a failed project included a claim by SAP of Waste Management “failing to timely and accurately define its business requirements” as a contributing reason for the failure.  
(see http://www.cio.com/article/486284/10_Famous_ERP_Disasters_Dustups_and_Disappointments). 

So, an organization cannot skip over or pay lip service to business requirements definition in software package projects. Done properly, good business requirements can be used to directly fill the part of an RFP that scares most people: the functionality and data that a package has to meet to be considered for purchase.

When first putting together a list of candidate packages, there may be a lot of vendors who claim to meet your needs based on a summarized description of their products; sending vendors an RFP containing good business requirements will quickly weed out the ones who don’t measure up. Many times, (good) vendors react to this kind of RFP by declining to respond when they see that their product really does not meet the business requirements; this saves both parties time and effort on a deal that would never have gone through. 

This will normally lead to a short list of vendors who have a product that could meet the requirements. Getting to one vendor usually involves product demonstrations, on-site trials and other means of evaluation. Of course, other requirements need to be met as well, perhaps technical requirements the software has to meet to run in the desired environment (although hosted and other “cloud” options are changing this). The best scenario is to have two or three vendors whose products will meet the requirements, after which the remaining negotiations can be about getting a good price … all because of having defined the business requirements. 

And last  but certainly not least, having the business requirements eases the implementation of a package. In decades past, buying a package meant buying code; if alterations to the package were needed, that meant changing code, and getting it to work. This was often difficult and would commonly void any agreement with the vendor to support the package and provide updates.

These days, good packages are built to be configurable. A vendor will often have consultants who can configure the package; and what do those consultants need as input? Your business requirements.  

If by chance and very good luck, the project has reached this without having defined the business requirements, they will have to be defined now if the package is ever going to work properly; and there is a very likely possibility that when the requirements are finally documented, it is clear that the wrong package was purchased. That’s when stories about project failures turn up in industry magazines and sites, and even the regular media if the failure is colossal enough.

So, you’re buying a package? Don’t forget your business requirements…

– David Wright, IAG Senior Consultant 

(For even more on the importance of requirements, see the Business Analysis Benchmark Study from IAG Consulting, see  http://www.iag.biz/resources/library/business-analysis-benchmark.html )

 

Track IPhone unique and for this reason can you track an iphone without special. I think that information interesting. Remember that. Also you will have no problems.

Four Trips to Midnight

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.

Continue reading

Collecting Requirements Review Checklist

Project Managers need to ensure that the collect requirements phase has been completed satisfactorily. This checklist provides a reference for elements that need to be defined.

You can find the checklist here

Track IPhone unique and for this reason can you track an iphone without special. I think that information interesting. Remember that. Also you will have no problems.

Checklist for Developing a Requirements Transformation Program

A Requirements Transformation Program

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:

  • Process
  •  Practices and Techniques
  • Technology
  • Organization
  • Deliverables / Results
  • Staff Competency

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.

  1. Use the Maturity Model as a framework for improvement
  2. Be forward looking, not backward looking
  3. Positive in reasoning, not negative
  4. Simple arguments get funded while complexity just confuses
  5. Be sensible about what can realistically be accomplished
  6. Spend your time asking good questions
  7. Get the hard facts: Include industry studies such as the CHAOS and BA Benchmark Reports
  8. 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

Click here to get the checklist

Track IPhone unique and for this reason can you track an iphone without special. I think that information interesting. Remember that. Also you will have no problems.

Specifying Report Requirements

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.

Continue reading

BI Requirements: Success Enablers

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.

Continue reading

Understanding Your Role in a Requirements Session

1. Requirements Team (Facilitator, BusinessAnalyst)
Enable the requirements discovery process by:

  • Asking relevant questions
  • Recording answers provided by SubjectMatter Experts
  • Keeping the process moving
  • Utilizing effective facilitation anddocumentation skills
  • Keeping the discussion focused onobjectives and scope
  • Confirming understanding among/withparticipants
2. Business Leader / Project Sponsor
Provide the business vision by:
  • Explaining the problem/opportunity
  • Defining the vision
  • Defining the business objectives
  • Determining the measures of success
  • Defining high level process andrequirements

Key Questions for Breaking Through on a Difficult User Story

The Challenge

User stories that should be simple are frequently quite complex, written ambiguously, or have underlying needs that are hidden below the surface.  Some should be broken up in to multiple stories.  You may not know how best to write a user story and communicate needs.  Many developers are not trained in the techniques needed to break through in this challenging environment and quickly get a clearer understanding of user needs.

Break Through Thinking

Make this break through:  it’s not the designs you bring, or the solutions you suggest, that will clarify needs – it’s the questions you ask that determine how quickly a solution can be implemented.  Good questions showcase your understanding and build trust between you and the user.  Here are a few situations where a few great questions will help you deal with difficult user stories and difficult times:

 

Determining the success criteria

Here is a simple approach to clarifying user stories: attach your clarifications as acceptance criteria or test conditions.  The user story could be all about the user interface. The success condition in the mind of the user could be very different “A user can buy our product.”  By focusing on the outcome not only is the capability needed clearer, but you also now have a clear understanding of what to focus on with users during sessions.

Continue reading

Determine when you are “done”

Four simple tests to assess if requirements are not done

These are Business Requirements level tests that work and will improve your requirements quality irrespective of delivery methodology:


If the requirements lack context: Requirements always exist to support “what” the business wants to do, not “how” it wants to do it. The “what” part of this is the context of business process. Lack of understanding of what business processes are impacted by requirements means someone has no idea of how requirements impact each other, the impact of removing requirements, or the ability to assure that the requirements collectively are complete or will meet a specific business objective. The way a company applies context in its documentation also creates the structure of the documentation.

If the interdependency is not evident: How do you look for proof that interdependency is documented? Look for a section in the material called “dependencies”, check the “issues list”, and look for an analysis technique called a context diagram (every line on a context diagram is an interdependency). Why is interdependency so important? There are two aspects to scope: internal to the system (e.g., its functionality, the workflow and information flow, etc), and external to the system (e.g., how this system needs to interact with other systems, how the workflow being automated hands off across other departmental units). In the absence of knowing the interdependencies, you only ever know part of the story on scope, so it becomes probable that you will encounter significant scope shift on any system of any degree of complexity.

Unclear business objectives: Objectives must be Specific, Measurable, Achievable, Results-oriented, and Time-bounded (easy to remember as ‘SMART’). The absence of objectives eliminates the ability to assess solution tradeoffs, makes difficult the prioritization of functionality, and other problems. You can test if a particular function meets needs with user acceptance tests. You cannot test if the collective system meets needs unless you have clear objectives.

  Continue reading