Tag Archives: business requirements

It Ain’t Easy Being Agile

Leave a reply

You have to admit – agile folks are conflicted. On one hand there’s the folks screaming requirements are dead***. On the other hand, people teaching agile practices have to explain the asterisks; mention these things called user stories and the practices of getting good user stories (like making each user story testable and how to deal with non-functional requirements). Then there are the folks rolling out these practices and using them in real life on complex engagements. We’re facing the issues of sequencing and redundancy of stories, figuring out which ones accidentally change the architecture of the system (oops!), which ones were really a whole book rather than just a story, etc. and how to actually get to the promised land of higher productivity. No wonder you get questions from developers like, “can I write down this non-functional requirement?” Agile is still a storm of mixed messages – and like the Internet bubble of the late 90s hype might do more harm than good to the movement over time.

 

itainteasy1

Continue reading →

What Is Requirements Discovery?

Leave a reply

Requirements discovery is also often referred to as requirements elicitation, requirements gathering, requirements analysis, and requirements definition. We prefer to use the term because it’s a little less high-brow, more meaningful, and more appropriate to the activity it is intended to describe.

The Requirements Discovery Process

Requirements Process FlowThe typical process for requirements discovery involves the following six activities:

> Requirements Planning 
> Requirements Elicitation 
> Requirements Analysis & Documentation 
> Requirements Verification & Review 
> Requirements Validation & Acceptance 
> Requirements Change Management

Origin of the Term Requirements Discovery

Legal DiscoveryThe term was initial coined by Ross Little in the late 80’s. Ross, now a principal with IAG Consulting, adapted the term from the legal profession. As a practicing Business Analyst, Little was working to evolve methods, practices and standards from the worlds of structured systems analysis, software engineering, total quality management and business process reengineering. Little credits his father, a lawyer, introducing him to the legal discovery process – and the genesis of the idea to apply some of those concepts to how organizations should gather information to define requirements for business solutions and change.

In the legal community “discovery” is the approach used to determine the facts about a case. Legal discovery mechanisms may be traced back to procedures of the ecclesiastical courts in England as early as the 16th century in which litigants delivered pleadings and obtained answers by means of examination under oath. As legal discovery in American law is the pretrial phase of a lawsuit, requirements discovery is the pre-design phase of a business transformation, or application development project.

Continue reading →

Requirements Maturity Checkup!

Leave a reply

How mature is your organization’s requirements practices? Now you can find out!

IAG Consulting has just launched a new (free) online assessment tool that will evaluate your requirements maturity based on 40 questions. The assessment is based on IAG’s industry recognized Requirements Maturity Model and will give you a report with your overall maturity score and some recommended actions for improvement.

Take the assessment

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.

Requirements Case Study: Michigan Department of Transportation

Leave a reply

The Michigan Department of Transportation Engineers New Approach to Business Requirements Definition that Saves Taxpayers’ Money


•      As part of an overall plan to improve project management, the Michigan DOT first turned to enhancing their business requirements definition process

•      Chose Safety Status System (a collection of systems that would let MDOT monitor and track the process of traffic and safety projects) as test case.  Project cost $1M

•      MDOT engaged IAG Consulting to facilitate the business requirements definition process and develop the system design document.

•      The IAG team compressed the requirements discovery into a 2 week timetable – 10 weeks from start to design

•      MDOT recognized the value of this immediately.  Initially, the business manager planned to open the session Monday, and then come back on Friday to see the results.  However, after the first few hours, he cleared his schedule for the week and stayed with the team.  This, he felt, was refining his business processes and eliminating duplicate work along the way

•      The resulting design document served as a RFP and the final project cost was signed at $670,000 – 33% less than originally expected

•      “In a fast-moving environment, the development job is never done.  But if you have a solid foundation from the start, you’ll likely have only minor modifications down the road.  We believe we will be able to hold our maintenance costs down thanks to the work we did in the up-front design process.”

 

“One of the reasons we chose IAG Consulting was they work with us to build internal capacity.  First our people go through a training session with IAG Consulting.  Then they work alongside the IAG facilitators.  In the third phase our people do some of the blocks, with IAG coaching.  Finally, they ‘solo’, with IAG there for support if they get stuck.  As a result, we have somebody in-house who can facilitate the process and keep our documentation on track using the IAG template.  I like that approach, because most consulting firms want to get into your back pocket and stay there.  With IAG, the knowledge doesn’t leave with them, so we retain the value and process.”

–         
Doug Couto, CIO for Michigan’s Department of Transportation

 

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.

Outsourcing the Requirements Elicitation Job to External Consultants

Leave a reply

What do you need the most when eliciting requirements? Face-time with Subject Matter Experts and their Managers.  As a Business Analyst employed in a typical organization, what is the thing you get the least of? Face-time with Subject Matter Experts and their Managers. Who will Subject Matter Experts and Managers make time to see? Outside Consultants.

Such is the way of the world, at least the one I have worked in for 30 years. Full disclosure: for about 20 of those years I was an employee Business Analyst. I am now an outside Consultant working in Requirements Elicitation, Analysis and Documentation. I have spent more direct time with SMEs and Senior Managers in the last five years than I probably got in those 20 years. Why? Because I have usually been brought in to work an important project, and I am a direct cost to the organization.

If you the reader are an employee working on projects, and not limited to Business Analysts, you know this true. Is it fair to you? Not really, but having been on both sides of this situation, I don’t see it changing anytime soon.

So rather than complain about it, how can you make this work for you? (And yes, what I will suggest should mean more work for me, but hear me out…)

Read the full article by David Wright, Sr. Consultant with IAG Consulting

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.

The Pendulum Swing of Organizations

Leave a reply

I wonder if organizations give out awards for surviving the most reorganizations in a single decade to particular business functions.  I’m thinking that most analysts get to experience this frequently as the pendulum of organizational design swings from housing analysts in the technology organization, in the business organization, centralizing or decentralizing.  As business reorganizes, technology changes alignment, and the moon aligns with various constellations, reorganization is triggered.  I’ve been asked to weigh in on this a bunch of times.  Here are some thoughts for whoever is gunning to get the new design in place for September.

There are Lots of Designs that Work, but Very Few Organizational Designs Promote the Goal of Improvement

If you have a team of BAs, you can organize by application, by business, by seniority, by type of BA, by geography, then you can organize management centrally, or by business line, or by matrix of business and IT, or … and the list goes on.  All designs are for a reason, so they will all accommodate some aspect of the culture or gap or improvement, or machismo that needs to be addressed.  Only some designs will promote the goal of improvement in the capabilities of BAs and consistency of service brought by BAs to the organization.  The designs that best enable improvement bring together and optimize three basic areas:

  • The Framework: What are the processes, practices, tools, metrics, deliverables and standards etc, of doing requirements?
  • The Resources: How are the competencies defined and managed, how is performance managed, and how are resources allocated to work?
  • The Infrastructure: This is the governance, business alignment, organizational integration k, etc.

The more fractured these things are, the more difficult to manage and promote standards and change. By the way, improvement may not be the primary organizational design constraint and sometimes you need to work with a suboptimal organization structure to enact change.

A Few Pointers 

Even when you have a poorly designed analyst organization, there are a bunch of things that can be done to make it function better. 

Centralize Analyst Work Intake. Even if the organization is a complete mess, centralizing the small function of estimation and work package creation pays massive dividends, especially when the analyst organization is larger.  And, it’s not expensive.

Think Services.  Sometimes it is not possible to get centralization on the entire analyst organization, but it is possible to get an institutional focus for a small set of high-end services, especially when these services are directed at success for larger projects.

Revise the Hiring Practices. I’ve come to the conclusion that a lot of companies don’t really know how to hire BAs.  I think people don’t realize it’s a tactile job, yet a lot of companies hire without seeing how a BA does these hands-on things.  It’d be like hiring a nanny without ever checking out how they interact with the kids.  I’m not talking about charisma or being personable here, I’m taking about aptitude and the ability to ‘do through interacting’.

Right-size the Organization.  One of the biggest oddities is the vast differences in size of the analyst function at different organizations.  Sometimes one or two BAs are driving $100M in projects, sometimes it’s over 100.  When you get way too few, the organization get really ineffective because all the people can do is be traffic cops and oversee the outsourcing of work.  When you get too bloated, the work progress slooooowwwwssssss waaaaayyyyy dooooowwwwwwwnnnnnnnnn; it’s painful to watch.  We get people that are used to taking a week to deal with what we deal with in a day – it’s really hard to reset expectations.  It’s not difficult to do know the right number of people, but hiring headcount is often difficult to deal with.

Be Positive and Patient. There is a time and situation when changing the structure of an organization  becomes dramatically desirable.  There are also times when no amount of executive discussion will create openness to change.  As anyone paying attention to the recent financial fiasco knows, external influences can create a 180 degree change in focus extremely quickly.  Timing and planning are everything, as are planting seeds for change … sometimes for years.  Remember, eventually, most companies try to do the right thing.

 

Click here to see the full article

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.

Analysis versus Needs Analysis

Leave a reply

Most analysts can do analysis…but very few can really be proactive in helping customers figure out their needs.  Executives routinely complain about analysts being passive on projects, not proactive, or inconsistent in their execution. I think this is a real challenge that needs to be addressed. 

Done well, business analysis is a leadership role; one that actively impacts the speed and outcomes of IT development activity.  In this leadership role, analysts have the skills to proactively lead stakeholder discussion and create information in a format that communicates well to both business and technology about business needs.  Analysts are playing the role of bridging the gap between business and technology. 

Without the right processes, techniques, skills, organization, technology and deliverables, analysts default to small ‘a’ analysis.  This is a reactive role, taking in projects and generating activity without momentum.  The clarity of need and outcome is simply not emerging rapidly enough, or with sufficient consensus, or with the right usability of deliverables.  Projects are more difficult with small ‘a’ analysts on your team.  Work may be getting done, stuff is happening, but how much momentum is really being generated?  How much do you need to rework the deliverables of those people?  How many times are you getting the right blocks of content filled in on templates, but very little being said?  Know people like this?

Am I really being too harsh?  To me it comes back to the role and expectations, and I believe analysts provide LEADERSHIP.  Part of this leadership value is that analysts be a strong source of momentum.  This means you can’t have situations like the above.

OK, so you’re looking around your organization seeing lots of what I’ve coined small ‘a’ analysts. What do you do?

There are a few short term tactics you can employ to refocus the value delivered by analysts, and one long term tactic.  In both cases YOU, the manager, need to own the situation you’ve created for yourself.

The short term fix is to focus on ‘elicitation skills.  They’re the methods and practices (like facilitation) of engaging stakeholders and asking the right questions at the right time to extract the information needed to determine business need.  This has immediate benefits in the focus of analysts and their abilities to engage stakeholders.

You can also implement a short term fix about quality standards:  getting away from defining the completion of the template as the standard, and going toward setting clear guidelines on the fidelity of information in the template.

Finally the short term fix could be to look at the services that your analysts provide to the organization and change the intake process for new projects that want to use these services.  It can have a profound effect if the requirements management team knows how to quickly understand the status of a project, and create more clearly defined work packages for their analyst teams from this understanding.

In the longer term, the management group has to assess requirements definition and management maturity, and set out a plan for improving this maturity level.  It’s the only way to get stickiness on change.  An organization cannot hope to make substantive improvement by focusing only on one capability:  skills (continuously training), process (continuously redesigning or enforcing a process), techniques (being militant about the use of certain standards), deliverables (getting people yet another template), organization (going from a requirements center of excellence to a center of practice), and technology (roll out something else… again!). 

Business analyst management needs to look across all capability areas and systematically improve the consistency of the organization across these areas.  The value of making this improvement is also extreme, doubling most performance metrics on projects.

Why do I get passionate about this?    Seventy five percent of organizations last surveyed were poor at doing requirements… 

To really meet business need, analysts need to be leaders.

Read the Article & Comments

 

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.

Choosing Business & IT Participants for Your Requirements Sessions (Video)

Leave a reply

Having the right mix of people is critical to the success of requirements elicitation sessions!

Click here for more on Choosing Participants for your Requirements sessions

 

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.

The Technology of Business Analysts

1 Reply

Here’s a personal opinion: Business analysts remain one of the last bastions of antiquated technology. Put up your hands all of you only using Word and Visio. Probably only 20% of you have requirements management software, and even fewer have requirements definition tools worthy of the name. Yet everyone is under pressure to improve performance and productivity – especially now that the economic recovery is underway and project pipelines are filling rapidly. Here’s a quick primer on the Dos and Don’ts of acquiring analyst productivity software.

OK, so analysts are the proverbial shoemaker’s children, always defining requirements for the solutions of others, and never for themselves. Unfortunately, this is the cardinal rule that many analyst organizations break – they don’t properly define requirements when they look for analyst requirements definition and management solutions. Seems a little crazy doesn’t it? A quick suggestion would be to step back from the glitz of the technology for a minute and perhaps run some facilitated sessions to identify the analyst processes, the information required to support these processes – maybe even identify a few interdependencies? Sound familiar? Once you do this, the wide variety of solutions out there start rapidly falling away – and very few likely remain.

Would it surprise you to learn that there are over 100 analyst tools that are well known enough for IAG to track them? Who knew the lowly analyst had so much choice? When you evaluate tools, it is easy to get caught up in the sizzle rather than the steak. The sizzle are the flashy functionality around the system that make it more flexible in execution. The steak is the no-holds-barred answer to the question, “what was this thing principally designed to do?”

Since the sizzle is infinitely more interesting, let’s start there and talk about the kinds of sizzle you can get in an analyst tool:

Tool Integration. All tools have a degree of model sharing; upstream (to portfolio management, or project management) and downstream integration (to quality systems or development). This model sharing is either fully bi-directional (YAY!), meaning changes in one system are reflected in the other, or it is accomplished by simple export (BOO!) which can lead to all kinds of synchronization problems between repositories.

Documentation Generators. All tools are either better or worse at generating standard document templates and some are fairly configurable so that you can replicate existing internal standards for information production. More critically, these tools either capture into the repository the changes made to output (YAY!) or they force you to edit the format every time you print the same report (BOO!).

Stakeholder Collaboration. Most tools have a degree of automated collaboration to capture stakeholder commentary which is free (YAY!) but some tools force you to license the viewers and collaboration engine (BOO!). Usually, there is an auditing capability for indicating who said what, giving traceability on stakeholder review, validation and acceptance content.

Model Sharing and Global Repositories.: Tools are typically designed to be massively multi-user (YAY!) or they are primarily a single user system that can share models between users (BOO!). The difference between these are the server database options, security/access controls, check in/out controls, model sharing options and controls, etc within the system. Many systems lack the concept of a’project which I think is a bizarre oversight. A project has unique attributes like a charter, stakeholders, objectives, etc. and would include one or more use cases from an enterprise requirements repository that could easily be sharing the identical use case out to another project being worked on by another analyst. Some systems enable these concepts, many do not.

Object Relationship and Impact Assessment. Most tools enable the user to define custom object types, however the big YAY is the ease with which relationships are established (one click versus, in some cases many, many, many clicks) and the degree to which you can compare object types or look at object relationships. This type of functionality is ABSOLUTELY critical for traceability management and impact assessment. Traceability and impact assessment needs you to first establish relationships between objects (which can be cumbersome in some tools), illustrate these relationships in standard models, and be able to show how relationships are impacted under changing circumstance.

Ability to Embed Analyst Best Practices into the System. In a bizarre twist of fate, the better a tool is, the more ways it has to represent information in the system and the less usable the system is ‘off the shelf’ without some amount of training. This is a good-news, bad-news story since better quality requirements definition and management systems are highly customizable, but it could potentially spell chaos for larger teams of analysts unless some standards are set. The best tools have package configurability and the ability to embed elements of your analysts processes into the tool – meaning you can preset what objects are called, the attributes of objects and even eliminate certain options that you don’t want available to analysts in your company’s implementation of a particular tool. The purpose is to force analysts to model specific things, using specific techniques, in specific ways.

I could keep talking, but remember, these functionalities are the sizzle, not the steak. Yes, they are important functionalities, BUT, you have to first and foremost decide what analyst business processes you are trying to support – just like you’d advise your stakeholders to do. When you only focus on the sizzle – every tool has some degree of sizzle and every tool has some degree of functionality in every area above. When you get down to the steak – tools were either designed to support certain analyst processes, or they were not.

Tools tend to fall into different categories based on what they were first and fundamentally designed to do. Often, if something excels at one domain, it is poorer in other domains. You need to step back and pick one:

  • End-to-End Suites. Take IBM’s Rational product line for instance, or a number of the Application Lifecycle Management (ALM) tools. Here the big difference is the scope of the software and component integration between the tools. These systems are principally designed to be end-to-end and you buy into the end-to-end concept rather than best-of-breed components. Inherently, this kind of design will have gaps. Some of these (like Rational) have requirements management (Reqpro/Doors) AND definition functionality (RRC), some are only requirements management tools. Some have the ability to manage conceptual and logical data models – others do not. Be careful.
  • Requirements Visualization Tools. These popular tools (like iRise or Microfocus’ TeamDefine) are mainly designed to allow stakeholders to interact with visual models of a system. I draw these into two broad categories: ‘Visualization’ tools allow stakeholders to visually experience the process flow of an application but they’d probably want an analyst walking them through the activity to talk about the specific rules and functionality. ‘Animation’ enables stakeholders to fully interact with the system interface, and by embedding data rules behind the system, the user can also experience error conditions and alternate scenarios by operating (or animating) the system. Both classes of visualization tools have numerous vendors selling quite capable tools. Other points of evaluation are the fidelity of the models you can create.
  • Requirements Modeling Tools.: There are tools like eDev’s InteGREAT (or Requirements Composer by IBM) that were principally designed for an analyst to model business requirements. Others, like RAVEN, are focused on a specific type of modeling (Use Cases) and are more ‘assistive‘ for analysts (where we’re using all meanings of ‘assist’ e.g., increase productivity, help the analyst learn, automate the production of something, and act to increase quality). The key differentiators between systems are the number of model types created, the model fidelity, number of domains of knowledge that can be created or managed – some only allow the modeling of process knowledge, others can model any number of dimensions of knowledge (Process, data, rules, issues, interdependencies/interfaces, training, etc) and the degree of knowledge transformation (given a text description will the system create graphical description and vice versa) or given a use case model and clear actors, can the system render a cross-functional swim lane diagram.
  • UML Modeling Tools. These deserve a special mention since the UML can be used to generate a rich model of a business process and identify/manage requirements. The upside to these tools is often the ability to forward and reverse engineer code or to model enterprise architecture. The downside is that you are locked to the UML and this modeling standard’s ability to resonate with business stakeholders that are not trained in the UML. The big differentiators here are very numerous since UML tools also get used across the entire application life cycle.

If you go beyond the above four areas there is also a whole series of tools from other domains like quality (HP’s Quality Center), Enterprise Architecture (Casewise), Business Process Management (IDS Scheer), process logic capture tools (StereoLOGIC), among others that are converging to better service the needs of business analysts.

The landscape is filled with productivity tools that are well designed to make analyst teams more productive. IAG has itself implemented or used most of the ones I’ve named here and we are resellers of more than six of them so I’ll not stand up and endorse one vision over another. The key is to recognize that there are choices – a huge number of them – and take the time to do the requirements analysis properly before selecting and implementing a system. As ironic as it sounds, it seems that lousy requirements definition is pervasive when looking at requirements definition and management tools. Use the purchase of a tool to figure out your analyst processes and to strengthen consistency. Don’t be the shoemaker’s child any longer.

Click Here for more Business Analysis Resources

 

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.