Making change requests tangible - the home reno

The cost of change requests are sometimes difficult for a client to visualize. This is especially true with software development projects. There is just nothing tangible a client can wrap their mind around. 200 lines of C+? 400 lines? What's the difference?

To make the impact of a change request more tangible, I suggest using an example most of us can relate to - home renovations. Last fall, I had a series of basement renovations performed. One component was to add a partial wall to split an area of a room off (notice the wall on left.)

After the installation of the initial studs and drywall, I decided the wall should be a little longer. This would provide me with the option of putting larger pieces of furniture on the other side (e.g., more shelves.) The contractor had to use more materials and time to extend the unfinished wall.

Had I realized my requirement for a longer dividing wall earlier, it may have saved my contractor some time (because I caught this early I didn't waste any materials.)

Now that the renovation is complete you can't even tell the wall was extended. I got what I wanted even though it took a little more time.

For arguments sake, suppose I figured out I needed the wall extended after all the painting, floors and baseboards had been installed. Considerably more time and material cost would have been incurred. Why?

If my contractor needed to remove flooring, drywall and repaint - I would have wasted a lot of materials. Some of the flooring and baseboards would have been thrown out, additional paint and priming time would have been required, etc... All of this costs money.

On a side note, the wife of a friend of mine was also performing a renovation - the kitchen. She decided to replace the marble tile pattern she had picked for the backsplash. She made this decision after the tiles had been bonded to the walls, grouted and treated (so oil wouldn't damage them.) My friend literally cried... he understood the impact.

The moral of the story - the earlier you can identify the need for a change the less costly it will be.

Avoiding inertia and estimating how long it will take to write requirements

Back in 2007, I decided to take a couple of months off from writing on this blog. A few months stretched into a few years really easily. Once a habit is broken, it's very easy to give into inertia. I guess this is why one should aspire to never miss a workout.

Recently, I received an email from Georgia on one of my posts in which she asks, "..., I was wondering if you have any tips on how to estimate how long it will take to write requirements for a project you've been assigned to. The project is new, you know nothing about the business, how can you provide an estimate? Should you just give a high-level estimate and then adjust as you go along and see the progress?"

Why do businesses execute projects? To improve how things work, to meet regulatory and compliance requirements, to capitalize on new opportunities or avoid potential threats.

At some points in your career you'll be asked to work on projects where you have little to no expertise. Don't be discouraged however, this is how we learn. What approach should you use to estimate how long it will take you to write requirements? Here are some thoughts:

1. Decompose the project into the key basic business processes which will be impacted (e.g., billing, order entry, inventory reconciliation, campaign deployment, etc...)
2. Create a matrix using the business processes versus the different stakeholders involved - such as finance, marketing, customer service, warehousing, etc...
3. Indicate which teams are involved in which processes and which team is the ultimate owner of each process (who do you go to if you need a decision.) The more teams involved, the more potential stakeholder complexity.
4. For each process indicate how complex you feel it is. If you don't know much about the process, rely on the stakeholders and management for guidance.
5. Using the information you've gathered determine which processes have high, medium or low levels of complexity. As a rule of thumb you could say high = 10 days, medium = 5 days and low = 3 days.
   
6. Add up the total number of days and this will provide a really rough estimate.

Understand this is merely a high-level estimate and as further analysis is performed the estimate will become more precise. This is project estimation after all. At the start, you might provide an estimate with 100% contingency, however as the project starts to execute the level of contingency drops as more things become known.

One side benefit of using the matrix is it will also help you plan out your requirements gathering sessions (you know exactly who needs to be involved for each process.) Use this to secure participation from those teams and your project's sponsors.

Webinar: Trace requirements to business intent

Compuware is providing a webinar on July 26 @ 2:00pm EDT. You can register following this link.

Practical techniques: Trace operational and other non-functional requirements to business intent
More and more there is increased pressure to develop applications that are closely tuned to business processes and yet can be changed on a moment’s notice to reflect new priorities.

Achieving balance between business goals and the associated operational requirements set has been a challenge. Too often different stakeholders are defining the business (domain experts) and operational (technical experts) perspectives. This can lead to disconnects in the systems delivered, requiring expensive rework either late in the development cycle or in post-production maintenance releases.

Someone else's shoes

Continuing from my last post, spending a day in another person's shoes will give you an appreciation and understanding of their point of view.
Try this simple exercise - Drop any preconceptions or notions you may have and pretend you are in the position of one of your clients or end-users. Do a little role-playing to increase your empathy.

• What would you want or need to be successful?
• Why would you want it? What would you do with it? What's the value?
  
• When would you need it?

By no means do I suggest you use this technique to gather requirements for a client, however, it will help you look at things differently and with a more open mind.

Change your perspective

Perspective influences how you view the world. It allows you to see things in a different light than another person, but it can also keep you from understanding their point of view. When you are gathering requirements from a client, having empathy enhances your ability to understand their needs.

Benefits of being able to view things differently:

1. Allows you to be open-minded, receptive and patient.


2. You learn to think like your client. In some of my engagements, I found my clients could not articulate exactly what they wanted. I needed to perform a lot of facilitation to help gather and define requirements. Being able to think like them allowed me to probe more effectively and determine the underlying objectives.


3. Because you understand your client's point of view, you can anticipate their next question. This is an excellent value-add to your ability to provide service.

Changing perspective isn't a foreign concept. If you have ever created user stories, you have in essence used an approach that incorporates the different perspectives of the people involved. User stories are easy for the different parties to understand -- clear communication is always the goal.

Make understanding your client's perspective a part of every engagement.

Slew of webinars and resources

Why requirements definition is a critical first step (April 18, 2007 @ 1:00pm EST)

Managing your requirements is only half the battle. For management to be truly effective, taking the first step of defining complete, accurate requirements is absolutely critical. In this webcast, Forrester Senior Analyst Carey Schwaber will explain how you can build agreement around requirements right from the start, so there are no uncertainties down the road.

Aligning Business and IT (on demand)

Many CIOs are struggling in their quest of aligning IT with the corporate business strategies, objectives, metrics and culture. CIOs need to become more involved in the development of strategic initiatives and build an understanding of the corporate and line of business missions and goals if they seek to align IT with the corporate directions. Moreover, CIOs need to interpret that knowledge into a flexible IT strategy if the alignment is to succeed long-term.

Business Intelligence Trends (podcast)

As business intelligence (BI) evolves, new trends emerge. But whichimportant BI trends should you pay attention to? And how should yourorganization incorporate this information into BI strategies?

Webinar: Requirements-driven testing

There's a webinar offered by Compuware called, Requirements-driven testing—The journey from business needs to test and user acceptance. The event will occur on February 6, 2007 @2:00 pm EST (11:00 am PST.) Here's a brief description of the event.

IDC’s research indicates that 70-80 percent of IT project failures result directly from poor requirements gathering, management and analysis. With a requirements-driven testing approach, you can improve the quality of your requirements, involve QA earlier in the life cycle and maximize the ability of your projects to deliver on all of their objectives.

Requirements in an agile world

In my last post, I wrote about differences between projects that use a traditional project methodology versus ones that employ a more agile one. In the post, Choose a methodology that suits your project, I spoke of when you should use one methodology over another one. Is there an impact on requirements from different methodologies?

Recall the main characteristics of good requirements:

• Correctness
• Completeness
• Clarity
  
• Consistency
• Testability
• Traceability
• Modularity
• Feasibility
• Design Independence

These factors are essential to all requirements. However, when using different methodologies there are slight variances a business analyst should expect. The two pictures below show my thoughts on the key differences.All business analysts should be aware of these differences and the impact to their deliverables.

Agile Project Leadership Article

There's an interesting article on ProjectConnections.com called Agile Project Leadership. In it the author, Kent McDonald compares and contrasts traditional project management characteristics versus agile project management ones.

To summarize the article, the basic differences were:

• Task versus feature driven.
• Process and control versus anticipate and adapt.
• Fully detailed versus iterative project plan.
• Leadership versus team driven.
  

To this set of differences I would like to add something from one of my previous posts, System Development Life Cycles & Requirements,

• Process versus people-oriented.

If project management characteristics change depending on the nature of the approach taken, what about the approach to requirements? What differences would one expect to see? What concepts are important?

VIDEO: Excessive Jargon

Here's a short video that parodies what happens when you use too much jargon. No one understands anything!

Disaster Recovery, Requirements Management & Alignment resources

Here are some resources I've come across that may help you.

Requirements management
Best Practices for Enhancing Project Success is a recorded webinar that you can watch at your leisure.

More than 70 percent of software project failures can be traced to poor requirements management. The root cause: the gap between what the business team wants, and what is communicated to IT for delivery back to the business.

Disaster Recovery
CIOs lack confidence in their DR plans

IT execs are insecure about their disaster recovery plans.

That's according to a new survey by Rochester, N.Y.-based Harris Interactive Inc. that reported 39% of executives polled gave their plans a letter grade of C or worse, revealing a troubling lack of confidence in disaster readiness.

The survey results also indicated that this lack of confidence in disaster recovery planning is growing. A similar survey conducted in 2004 found that only 24% of executives gave their plans poor grades.

ALL-IN-ONE GUIDES: Disaster Recovery

This All-in-One Guide will get you on the path to a good, solid DR plan and show you what you need to do to maintain it. It starts you off with DR planning and design with understanding recovery capabilities and tools, and then takes you right through to DR implementation, security and testing.

Alignment
IT/Business Alignment

The IT/business alignment topics page provides CIOs and IT management with up-to-date information and resources on budgeting, IT governance, IT spending, leadership and strategy, and Return On Investment / Total Cost of Ownership.

Webinar: Using ITIL to Align IT with Business Requirements

Here's a link to an on-demand webinar that may be of interest. Below is the description.

Increasingly, enterprise IT organizations are managing IT as a set of defined, customer-facing services. This concept of IT service management allows IT organizations to better package what they do for their customers and to more closely align their capabilities with business requirements. The worldwide de facto standard IT service management framework is the UK-government developed IT Infrastructure Library (ITIL). ITIL provides guidance on the most fundamental IT operations processes and is used by leading companies around the world for risk reduction, quality improvement, legislative compliance, and cost control. This webcast will introduce IT service management and ITIL with emphasis on the fundamental concepts and principles that IT executives need to know during the decision making process.

Do you see what I see?

I've been goofing around with a Nintendo DS Lite trying to reduce my Brain Age (I'm hovering around 23-24 for anyone interested.) One of the more interesting exercises in the game is something called the Stroop Test.

The Stroop Task is a psychological test of our mental vitality and flexibility. The task takes advantage of our ability to read words more quickly and automatically than we can name colors. (University of Michigan)

The object of the test is to say the color not the word. For example, if you saw BLUE, your answer would be, "Red!" The Brain Age test is basically to answer 50 of these items as fast as you can.

This got me thinking about how this relates to business requirements and clarity. One party sees, "Red," while the other sees, "Blue," even though they are both looking at the same thing. Furthermore, both parties think they understand completely. Hence, techniques like active-listening need to be used.

Of course, the Stroop Test probably won't work if you have a condition called synesthesia, but that's another story. A common form of synesthesia results in an affected individual seeing letters and numbers in color.

Poll: What do you use for requirements management?

What requirements management tool do you use and why do you use it? I've placed a poll on the right menu bar.

What do you like about it and what don't you like?

An RFI defined

What is an RFI?

A request for information (RFI) is a formal request made to a vendor (or service provider) who's aim is to ascertain whether a vendor's product would be suitable for addressing a company's need.

In a previous post, I mentioned that there were a few ways to get a solution:

1. Leverage existing systems.
2. Extend existing systems.
3. Buy a vendor product.
4. Build a solution.

An RFI is used as one of the earlier phases of determining which (if any) vendor products fit; thus if you should buy it. Prior to performing an RFI, a high-level understanding of a company's needs are required as well as a short analysis of vendors who may possess suitable product offerings.

Why do we use RFIs or RFPs (Request for proposal)?

We don't need to build everything do we? Just because we can do something doesn't necessarily mean we should do something. Basic economic theory has something known as comparative advantage. This theory is usually used to describe international trade but I feel that it can be applied to many other situations.

Suppose a company has limited people resources but these resources have the expertise to develop either spreadsheet or IVR applications. Also, suppose that the company needs both of these applications but can only do one or the other. Because we know that there are suitable products that support spreadsheets, is the company better off purchasing a spreadsheet application and building their IVR applications versus attempting to build everything themselves?

Unless something is a strategic differentiator, if suitable offerings exist, you should use them. This allows you to concentrate on the activities that are key to your company.

Parts of an RFI - The introduction

• Confidentiality agreement - You will be sharing information about your company that you do not want distributed to anyone else. Thus, before an RFI can be sent out, you must have a signed confidentiality agreement from prospective candidate vendors. Your company's legal team must approve both the RFI as well as provide the confidentiality agreement.
• Corporate overview - This information is provided to give vendors insights and context into what your company does.
• Project background - State what the project is trying to achieve as well as where you are in the process (what steps you have done or are in the process of doing.)
• IT overview - Give the vendor a basic idea of the types of systems their solution will have to interact with (e.g., we have mainframes, IVR systems, we use J2EE and Oracle.)

Parts of an RFI - Description of the process

• Timelines - Provide timeframes for RFI completion and evaluation.
• Post RFI participation needs - State what the process will be after receiving the RFI. Will there be a need for face-to-face conversation to go into more depth? What follow-up will you want to do (e.g., reference checks & demos)?

Parts of an RFI - The questionnaire

• RFI questionnaire - An elicitation of the basic requirements that need to be met. Obviously, a high-level understanding of your requirements is needed, but not a detailed one. Prematurely getting into too many details may bias your RFI and lead you towards a build mentality! Major non-functional requirements should also be stated (e.g., projected capacity, availability.)

Summary

This post is not meant to be a guide on writing an RFI but rather to give you a basic introduction to the purpose and components of one. RFI's are extremely important as they can lead to the purchase of expensive products and services. An inappropriate product choice can cause a company more harm than good.

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:

1. Identify the initiator and actors of the process.
2. Be technology and system agnostic.
3. Understand what is required to move from one part of the process flow to the next.
4. Show the main process flow not the alternates.
5. 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.