From start to end

Simple process flow diagramming - Part 2

Let's expand a little on why initial process flow diagrams should be kept simple. Answer this question, "For a process, is it more important to know what or how?" The how question can lead you down a treacherous path.

Common Problems

Effort becomes focused on specific details too early in the requirement gathering process. Eventually, the prototypical, "I can't see the forest for the trees," scenario occurs.
Mysteriously, the to-be process looks eerily similar to the as-is process in terms of the different steps that are undertaken. Problems inherent in the as-is solution may still exist in the newer one. I can't tell you how many times I've encountered this problem. People are generally resistant to change. There is comfort in the familiar. Sometimes, people just don't know a better way to do something.
We end up spending excessive time defining a to-be process that restricts our thinking and may not be used. In short, we are designing a solution.

To be or not to be?

Think of it from the perspective of a company trying to come up with a solution to a problem they are facing. Ultimately, there are a few different avenues: buy, leverage (what you already have), extend (enhance what you have) or build (from scratch). If I use a complicated process to evaluate vendor products, it is very unlikely that I will find one that meets my requirements to a tee. Instead, I may conclude that, "We are unique and as such no vendor product suits our needs. Thus, we must build a solution."

Think about how many companies you've encountered in your life that were truly doing unique things and compare this to the number of companies that thought they were doing unique things. A rose is a rose is a rose.

To me, this is the worst outcome. You have already, determined your path without realizing it (you have, in effect, not been solution agnostic.)

In Conclusion

You may choose a less optimal solution path (e.g., build something that can be purchased.)
You have not used your time effectively.

These things represent inefficient use of time, resources and money. And the ultimate solution may not be as efficient as it could have been.

Simple process flow diagramming - part 1

A picture says a 1,000 words... or so the saying goes, but do you really need 1,000 words to communicate a process? In truth, it depends.

Many times, on business analyst engagements, I've asked people to describe, in picture form, the basic processes that are important to their business. What I usually received was something that required a plotter to print... a huge, complicated process flow that took into account every single odd-ball anomally (even if it would only occur every 5th blue moon.) Why did this happen?

Subject-matter-experts (SME) can talk ad nauseum about what they do.
SME are detail-focused people; every detail is important to them.
SME do not like to see their business processes trivialized into one or two little boxes on a process flow diagram.

My own learning point was to find another way of getting what I needed to know rather than ask this of the SME directly. When diagramming a high-level process flow I usually follow some basic guidelines:

Identify the initiator and actors of the process.
Be technology and system agnostic.
Understand what is required to move from one part of the process flow to the next.
Show the main process flow not the alternates.
Understand the goal of the process.

The time will come when more detail is needed and the process will be flushed out. But I do not feel you have to start like that. Simple and elegant always win out.

Online webinar for requirements management

There is a webinar coming up on June 21, 2006 entitled, Requirements Management: Best practices for enhancing project success. Follow this link to register for it.
Here's a brief description directly from BZmedia, Get to the bottom of the prime reason for project failure--poor or incomplete requirements capture and management. Geared to project managers, business analysts, architects, developers and QA/testers, this session will highlight the benefits of structured requirements with SteelTrace to all stakeholders.

How are your business analysts doing?

How do you determine how well your business analysts are performing?

There are a few different aspects that can be used to measure your business analysts. When I say measure I mean from the perspective of areas for improvement and to understand the strengths and weaknesses of individual analysts.

Deliverable quality
I already wrote about how to assess requirement quality. Use requirement clarity, completeness, consistency, testability, traceability, modularity, feasibility, design independence and correctness to assess the quality of the deliverables.
Meeting expectations
As part of any engagement, a business analyst needs to set expectations regarding the deliverables.

What are the work products to be delivered?
What tools and applications will be used?
What is the estimated time required to complete the deliverables?
Who needs to be included in the process?

Basically this amounts to a business analyst following through on what they said. However, some leeway is needed to allow for the use of different approaches when the situation warrants it. Flexibility is important afterall.

Soft skills

Professionalism and conduct
Development of relationships
Facilitating understanding across the business and IT teams.

Conclusion
Ultimately, the outcome of a project determines its success. When looking at the business analysts involved you can measure them based on three basic areas:

Quality: Quality of deliverables
Time: Meeting of expectations
Resources: Facilitating understanding, development of relationships and professional conduct.

Assessing requirement quality

How do you assess the quality of your requirements? We know that requirements change over time. We know that sometimes we are working on projects in areas where we are not subject matter experts. We know that there can be many unknown unknowns. So how do we know we have a solid set of requirements?

A while ago I posted a series on characteristics of good requirements. These characteristics can be used as measurement criteria for quality.

Items to consider:

Clarity - You should be able to provide your requirements to an uninvolved third party and they should be able to understand what you're trying to say.

Is there a lot of jargon being used?
Is the language used simple and concise?
Can alternative meanings be derived (e.g., ambiguity)?

Completeness - Understanding whether a body of work is complete may be a little tricky. If there are common industry models that relate to your project compare and contrast them with what you have. Gaps may emerge that indicate missing requirements.

Do the requirements provide a sufficient level of detail and understanding to the business need?
Do you understand the context and how groups of requirements fit in with the entire body of work?

Consistency - Inconsistent messages are like bad driving directions, you may never get to where you wanted to be.

Are there contradictions in the requirements?
Is the terminology used consistent in it's meaning?

Testability - Requirements must be determined to be fulfilled or not.

Is there a way to test the requirement? Are there proxy tests?
Are there many requirements joined together (e.g., the word "and" is used often)?

Traceability - You can trace forwards and backwards and prove that your needs are being accounted for.

Can you determine which high-level requirement a low-level one belongs to?
Can you determine what are the higher-level requirements that lead to a low-level one?

Modularity - Making changes as simple as possible.

If you have to make a change, do you only need to make it in one place or must you correct many different places in the document?

Feasibility - Add a touch of realism. If you are a marketing company, it is probably not feasible for your team to design a rocket ship.

How realistic are the requirements based on your understanding of the client's goals, objectives and capabilities?
Is it even possible to do what is being asked?

Design Independence - Requirements should be agnostic of technology and speak only of business need.

Do the requirements answer the "what" questions or the "how" questions?
Are the requirements trying to fix a problem with an existing system rather than defining a business need?

Correctness - Everything must be in accordance with legislation and client guidelines.

Is everything legal? What guidelines or legislation must be followed?
Is everything ethical?

Epilogue

When examining requirements documentation these questions can help you get a grasp on the quality of the requirements. High quality requirements contribute significantly to better products. A previous post, Why you need good requirements, explained the rationale for wanting solid documentation and the potential consequences of poor requirements.

Improving clarity in communications

One of the most important skills you can master is to be able to communicate effectively and efficiently. In the past I wrote a few pieces on improving clarity for requirements and presentations:

I've decided to summarize the main points from these three posts into a presentation deck. As usual I've uploaded the deck to esnips.com so please feel free to access it (I've used high quality images so the file is on the large size.) The file is called, Clarity, and you can access it here. As always, any feedback is greatly appreciated.

The ignored step-child - the non-functional requirement

There have been some very interesting posts on non-functional requirements taking place recently.

About a week ago I posted, an item called Non-functional requirements & QA test strategies that was based on a comment received my leathej1 for my non-functional index as well a link to his post, The Fallacy of Non-Functional Requirements. The thrust of leathej1's idea was that non-functional requirements need to be collected in the same manner as functional requirements. This concept comes from his experience in quality assurance; where response times and performance targets are important to a system's acceptance. He made an excellent point that these sorts of items are usually given little consideration.
As a follow-up to leathej1's post, Scott Sehlhorst put up an article called, Non-Functional Requirements Equal Rights Amendments. Scott proposed a different way of looking at functional and non-functional requirements.

Read these articles, they're excellent.

Why you need good requirements

Why are requirements important to a project? The answer may seem trivial but let's look at some empirical evidence.

According to the Standish Group's chaos report (1995), only 16.2% of software projects are completed on-time and on-budget.
The KPMG Canada Survey (1997) stated that over 61% of projects were deemed to have failed.
According to Forrester Research, "No single factor is responsible for more wasted effort, rework, or failed projects than inadequate requirements (Carl Zetie.)"
Borland recently posted a new press release for Caliber DefineIT in which they state, "Analysts ... cite inaccurate, incomplete and mismanaged requirements as the number one reason for software project failure. The Standish Group's annual CHAOS report indicates three of the top five reasons for project failure are related to requirements. In addition, requirements errors are a primary factor behind most rework efforts, which ... can add up to 40 percent of the total development effort within a given project."

Let's also consider trends in business.

We are dealing with more complex systems.
We need to move faster because the business environment is changing faster. We need to react more quickly.
Project teams are moving towards more people-oriented development paradigms (e.g., Agile.)

What does this all mean? Successfully delivering projects (e.g., on-time and on-budget) is a difficult task. Furthermore, the environment is evolving and becoming more complex than ever, making a difficult task more even difficult.

I remember talking to a small group of business folk about requirements management practices and its importance (I've uploaded a variant of the presentation I used, titled The Need For Requirements.) It was very encouraging to watch the expressions of the different individuals as we went through the conversation and they started to appreciate the complexity of a project and their role. Understanding is step one.

Online folder for file sharing

One idea I've been toying with is the proliferation of materials I've used to foster more understanding and learning for others as well as myself. To this end, I've added a new icon on my menu bar.

If you press it you'll be directed to the esnips.com folder for this blog where you can get access to some of the slides and presentation material I have created. Feel free to use the material, I only ask that you credit where appropriate. One thing to note, as you look at the presentations, they are done in a very visual style. There is a bit of information on the notes pages to provide context to the presentations; so I suggest you look at them.

I've been writing a lot about presentation skills and requirements, so this is your chance to see how well I, "walk the talk." If you have any comments or feedback I'd love to hear it.