Just a reminder - you never know who's going to walk through the door

We had what I like to think of as a "consulting skills 101" moment as a nice reminder to “Be nice to everyone at your customer site…you never know who is about to walk through the door.”

We were in a meeting room waiting on our stakeholder. Two guys walk in saying they thought they had the room reserved. I told them I had received an acceptance on the reservation, but also offered to leave if they needed it (as we were only 3 people, and I was thinking they might have more attending theirs). They offered they would rather go find another room with a better projector. The point is I really was just trying to be polite to these complete strangers….and they weren’t being pushy, but if they had, I’d have let them have the room without hesitation.

So about 2 minutes later our stakeholder shows up and we start our meeting.

Another minute or so later…a man opens the door and walks in. He stops in his tracks when he sees us, and announces quite firmly “I have the wrong room!”. I got over my urge to cringe and instead just let him know they had gone to find another room. He smiled and left.

Why did I cringe you ask? Because he was the CEO of an F500 company. And now our project team jokingly asks me when I schedule rooms if I'm kicking the CEO out for that meeting too.

Anyway, what I will say is that none of them missed a beat - they could have played the hierarchy card on us at any point and they didn't. A sign of great character!

Project Pulse - Constraint Tracker

I was just wrapping up a project co-writing a 90 page requirements document for a client and I am so proud of my work! Unfortunately our statement of work with the client says that we would only document at most 45 pages estimated at 3 pages per requirement. With this data in hand we were able to approach the client about this potential budget buster. We were both able to come away from the situation happy due to extended budgets and robust requirements. What if this happens to you? What if you aren’t working on a project that has the luxury of flexible resources? Are you prepared to protect it from hitting that brick wall?

You probably need some sort of daily gauge letting you know where your project is in relation to your constraints. Some common project constraints are pages of documentation, number of requirements, hours, or budget. Try to keep track of these stats daily to maintain a dashboard both for yourself and for the stakeholders on your project.

It could look something like this:

These graphs will provide you with a quick easy to understand overview of where you are with your project constraints. With this understanding, you can better direct your work or your teams and when needed, go to your stakeholders and tell them that they may not get what they wanted with evidence why. It could motivate them to provide you with the additional resources you need to get the project completed right!

Register now for REET09 and RE09!! Early registration ends Monday

Please join us for an interactive discussion at the Fourth International Workshop on Requirements Engineering Education and Training (REET'09) in conjunction with the 17th International Requirements Engineering Conference (RE’09). The workshop will be held in Atlanta, Georgia, USA on August 31, 2009.

If you have any interest in training and education in the fields of requirements engineering, business analysis, or product management - this will be an exciting day to learn about new ideas in the field!

Following the success of the first, second, and third International Workshop on Requirements Engineering Education and Training (REET 2005, 2007, and 2008), this workshop will address issues related to RE education, both as part of a formal university degree and as ongoing skills training within the workplace. The workshop is intended to go much deeper than a surface discussion of curriculum issues and will examine specific ideas and techniques for teaching skills needed by an effective requirements engineer.

Out of Scope Out of Mind

Be wary the out of scope feature pile. Sure it is a quick and easy way to kill off an entire new project's worth of work, but did you kill it the right way? Make sure that when moving requirements to an out of scope status that the reasons for the decision are recorded and who made those decisions.

The best case will be where the feature has been mapped against a business objective that will not contribute enough to the organization's end goals. Can't argue when someone's favicon didn't make the cut since it would provide an estimated 2 cents to the yearly income from bookmark recognition.

The worst case will be a project's funder coming to you asking why his requested feature to save sales proposals in the system didn't make the cut while you stare blankly at your documentation looking for anything.

What is the Value of that Feature?

Alright. You've just identified the features that your client doesn't need going forward, the ones they can hold off on for now, and the ones that have to be implemented with the project. How did you come to that conclusion?

Were all the different group's champions in a room with you giving the thumbs up or down? Did the project funder push their features through? Maybe the cries of anguish from users as you held a feature over the out of scope bucket let you gauge how much it was needed. Are any of those a sound business case for the need of a feature?

Depending on the grandeur of your project, maybe it is. My bets are that it isn't enough. To really know what should or should not be implemented, every feature should be tied to a business objective. At the highest level you should have something along the lines of increase sales and decrease costs. From these you can have supporting objectives such as training sales, increasing client meetings, reducing cost of proposals, etc.

So did the project really need the feature to search for client information? I would imagine that kind of feature would be tied to an objective to allow for easier access to operational data, which ties to another objective to reduce costs of supporting client request. Given that, you should have a list of measurable KPIs (key performance indicators) for these objectives. This case might have a measure of the number of client requests for data per day and how long it takes to resolve the request with and without the search capability.

Now you will have to compare how strongly this feature affects the objective to reduce costs of supporting client requests. If there are a few other objectives that tie into this one, then you might imagine that the easier access to operational data could have a 20% correlation to the parent objective. From there you can take your current costs, multiply it by how important reducing costs of supporting client requests is and then multiply that against how important easier access to client data is.

So for example, let us say that our costs are $25,000. Turns out that reducing the costs of supporting client requests objectives is 30% of that cost. Now all the sub objectives are worth some part of $7,500. We said that the objective to provide easier access to client information was contributing 20% to its parent objective. This means that it is worth $1,500 of your costs.

Now you know that not having the feature costs you $1,500. You can estimate the implementation costs of the feature as well. If the implementation is higher, then arguably the feature should not be built. If the implementation cost is less than the value of having it, then you may want to build it, but at that point, you should compare the value of all the features in case you cannot build them all – choosing the ones with the largest value.

Six Ways To Be An Agile Adolescent

Do you get along with everybody? Are you universally loved in your office?

Then you are a failure.

There are those that are born great and those that are told they are great guys. Especially working in an Agile environment, the requirements stakeholder has to be… well…

A screaming, pouting adolescent.

They don't call it a scrum for nothing: It's a battle. If you're not arguing, not giving voice to every seemingly petty impulse, you're not doing your job. But don't worry, I can help you tap into your inner child. Start with these techniques:

1. The Eye Roll: This classic we all mastered as teenagers-- stop a line of BS before it starts (you should know it when you see it, you're the adolescent, after all).

2. Belch if You're Bored: You should never be bored in a scrum. If you're bored you're not on task. If you're in a meeting [which should be a warning sign in and of itself] try a combo: belch, then eye roll, then moan "What are we doing here?" Sartre would approve.

3. The Pedantic Reductionist Humiliation (PRH): When you need to prove a point, paint the picture out in irreducible terms and make other people say it back to you, ESPECIALLY if they don't want to. Chase people down and pin them; the rhetorical equivalent of "quit hitting yourself".

4. Appropriation of the Winning Argument: This is a great technique. If you find yourself wrong, just switch sides immediately and congratulate yourself.

5. The Schizoid Handshake: When things get really heated, wax philosophic and say "I really appreciate the interaction here. This intellectual energy is critical to creating a good product." Feelings don't get hurt as easily if everybody thinks they're part of an exclusive group, like hanging with Dorothy Parker at the Gonk**.

6. Forget Everything by Monday: Remember everything that happened in the trailing 48 hours then forget about it (this includes grudges) unless it is a plotter printout posted on a wall in your immediate work area.

The only nice thing about the business of being a child is that, while perhaps unpleasant, your role is critical.

Without you, things stop moving.

Five Tips For Creating Successful Projects in a Down Economy

We are certainly living in interesting times, and according to conventional wisdom, it is a curse to live in interesting times. Changes in our world happen almost overnight, from the political to the geographic to the financial. Pundits, pollsters and prophets may disagree on many things, but for now, most agree that the global financial outlook for 2009 isn’t good. Recent publications targeting everyone from requirements analysts to CIOs have espoused the importance of good software development practices in the face of bad financial times. While those articles may speak the truth (and I believe that they do), unfortunately some of us will face cutbacks in resources in the coming year.

Also unfortunately, requirements management is one of the software development areas that often gets put on the chopping block during resource cuts (along with other important areas like usability, user documentation, testing, architecture and even coding itself). As software requirements practitioners, it behooves us (yes, I said “behooves”) to be prepared for any reduction in requirements management resources, whatever the reason. Given the current financial environment, though, the need to be prepared may take on additional importance today. Hopefully the following five simple suggestions will help you be prepared in case you’re faced with this challenge in the coming year.


1. Establish and use a requirements management framework

Many times, requirements management teams sprout out of necessity. The ways in which requirements are elicited, documented and managed may be ad hoc, or even haphazard. When there are enough people to manage that sort of process and catch things before they fall through the cracks, such an ad hoc approach may suffice. When resources are limited, though, expending energy to reinvent the process wheel on each project is no longer an option. By establishing a requirements management framework complete with standard methodologies, processes and templates, you will take the guesswork out of your requirements work. A standard framework also helps you evaluate each project’s needs objectively, making those inevitable conversations about what can and can’t be done within a limited timeframe and with limited budget a bit easier.

2. Use tools effectively

One common piece of a requirements management framework is a suite of tools. Requirements tool categories range from document management to team collaboration to requirements documentation and traceability. While each type of tool certainly has a place in requirements management, they are often viewed as quick-fix solutions. An attempt to put a toolset on top of a broken process, or to simply replace requirements analysts with a requirements management tool, is likely to fail. Instead, recognize the specific tasks for which tools are good and use them for those. Version control, traceability management, spell-checking, and document generation are easy tasks for a computer. Talking with users, pulling together different pieces of information into a sensible whole, and drawing conclusions are better done by people. Remember that tools alone can’t fix a broken requirements process – tools are aids for, not a replacement of, skilled analysts.

3. Use metrics to reinforce the value of requirements management

Unfortunately, just saying that you have a framework in place and that you’re using tools effectively might not be enough evidence of the value of requirements management. If you’re not already doing so, begin capturing metrics in order to reinforce the value your work provides – you can start small and expand the scope of your metrics in order to fit your particular organizational situation. Some sample requirements metrics include rate of requirements change, percent of requirements implemented, and average time spent to document a requirement. While these metrics may be interesting for a single project, they begin to provide real value when they are compared over time, indicating how the framework is improving requirements practice. In addition to capturing requirement-specific metrics, it is extremely valuable to capture project-level metrics, including user adoption, user satisfaction, usability, achievement of project objectives, and return on investment. When you can show how your requirements work positively impacts the company’s bottom line, you take requirements management off the table during discussions of resource cuts.

4. Employ a satisficing approach, focused on what’s important right now

Generally speaking, satisficing is an approach which focuses on adequacy over perfection – you’re done when you have a “good enough” answer, rather than “the ultimate” answer. For example, I recently sent an SRS document out for review even though it wasn’t complete. The information I did have was good enough for comment by my reviewers, and the feedback I received from the team helped me know what other information was required in order to move us to the next step in the development process. Another example of satisficing in requirements management would be documenting the high-priority use cases in formal detail, while simply capturing a skeleton of the lower-priority ones. Satisficing allows you to continue to make progress on the overall project even when you don’t have all of the information that will be required eventually. It also shows the rest of the team that you’re interested in working together on the highest priority issues, rather than sacrificing “the good” in an effort to reach “the great.” Chances are, “the good” is indeed good enough.

5. Strengthen interpersonal relationships, both horizontally and vertically

When there are fewer people around to do the work, you may have to rely more heavily on others to help you succeed. It’s easy to see how important your relationships with other requirements practitioners are, but your other relationships within the organization are also more important than ever. Being able to turn to your documentation specialist for a review of your SRS, or getting an early heads-up from the development team about the feasibility of implementing a requirement, or simply knowing that your team is functioning as a team rather than a group of silos, can be invaluable during lean projects. In addition to shoring up relationships with your peers, this is a great time to establish or strengthen ties up the org chart. Many people aren’t as comfortable speaking with managers, directors, and VPs, but having their support for you and your work can help prioritize requirements management among their peers, and any support we can get from management is great!

Interesting times often call for simple, direct solutions. If your requirements management group isn’t impacted today, hopefully these suggestions will provide you with ideas for ways to make sure that you won’t be tomorrow. If you do face challenges as a result of the current financial environment, these suggestions should help you do more with less.