Monthly Archives: January 2006

iRise – software prototyping tool

irise logo

We received a comment from Tom Humbarger at iRise on an earlier post, which led us to take a look at their site.

iRise provides a tool for rapid prototyping of web-based applications, and there’s an overview of the products available. They have iRise Studio which allows people to create interactive prototypes of web-based applications, and iRise Reader that allows people to interact with their prototypes.

This is a good news, bad news, good news (at the end) situation.

The good news – they have an innovative idea – use prototypes to communicate requirements.

The bad news – Our initial excitement about their product quickly turned to skepticism while reading their copy…

Who are the target users?

iRise Studio is a powerful, easy-to- use application definition solution used by business experts to quickly assemble functionally rich simulations of Web-based applications in a matter of hours.

We are firm believers in the power of prototypes – especially when they can present a compelling vision for an application. The idea that a business expert can create a good one seems a little far fetched.

They’re going to do what?

Business people can quickly lay out the page flow of simulations and create high fidelity pages that precisely mimic not only the look and feel of the final application, but the business logic and data interactions as well.

OK, page flow of a mockup, maybe – but business people will not precisely mimic the look and feel of the final application. Even if they could – it would be a bad idea. We’ve talked about the imperative of not specifying implementation details as part of the requirements process. Specifying implementation details is one of our top ten use case mistakes.

The idea of doing the data modeling and business process simulation is cool. Lombardi Software, another Austin company does this stuff – but for enterprise clients. Some of the best people I’ve worked with are at Lombardi, I respect their opinions, and know that they are big fans of being able to do process modeling – and have it drive applications in the real world. If iRise has a comparable interface for modeling, it could be a great tool for rapid prototyping.

Why would they do that?

The interactive simulations can become visual contracts between business and IT, serving as stable blueprints for what to build.”

OK – now I’m getting concerned. Why is it a good idea to have non-experts specify the branding, layout, interaction design, and usability of a web-based application? Assuming that an expert business process modeler is at the helm, we can expect that high-level workflow is well designed. But the user experience? Show me a business expert who’s competent at designing interfaces and I’ll show you a switch-hitter currently occupying the chair of a business expert.

But we need a good prototyping tool!

The screenshots showing how the application is used to build prototypes look very cool. This application looks like a good product, but their marketing copy sure is targeted at doing the wrong thing. Check out the bits about modeling of scenarios too.
What about the testimonials? Maybe we’re missing something.

Here are some excerpts from the testimonials (note: we’re starting to get excited about the product again)

    • …allow us to rapidly and iteratively validate the client’s needs early in the process ensuring we have the right requirements from the start
    • to visually validate requirements and “test market” applications prior to investing time and money in development
    • can engage their business stakeholders early in the process to visually identify missing system requirements, eliminate unnecessary functionality and discuss important process and policy issues

    Yes, yes, and yes!

    This is exactly how a prototype should be used.

    What should iRise do?

    1. Change the way they propose that their clients use iRise. Business analysts, while ideally suited to identify, prioritize and validate requirements, are in no way suited to the designing of software solutions. User experience experts are. A picture is worth a thousand words, and an interactive prototype is worth a thousand pictures. Why risk misleading or dissatisfying the stakeholders with a bad prototype? Why prevent your development team from being able to apply their skills to design a solution? If you’re outsourcing to a development group with limited capabilities, this mindset might seem rational. The answer is to bring design resources in house, not ask non-designers to design.
    2. Find small consulting companies with a lot of passion for product success and a big megaphone (hint hint), give them a free copy of the software, in exchange for an honest assessment of how well it works and suggestions on how to incorporate it into effective software development processes.

    Dilbert does product managers

    dilbert official logo

    http://www.dilbert.com/comics/dilbert/archive/dilbert-20060129.html

    We won’t copy the image of the cartoon – but we’ll tell you that it opens with Alice: “I’ll need to know your requirements before I start to design the software.

    ObRelatedTopic: How to interview when gathering requirements

    Great Dilbert products

    dilbert book coverThe latest book (Nov 2005) from Scott Adams, Thriving on Vague Objectives

    From D. Reller:

    Another Dilbert collection, another great Dilbert collection. Highly recommended, of course, if you work in an IT/IS/MIS department, or just in an office. They never get old, or out-of-date. Mr. Adams hasn’t slowed down or backed off one bit – Ratbert the $100 million CEO-reject, multiple Wally updates, Dilbert and dating….

    Reading too much to buy another book? Check out the DVDs
    dvd cover art Dilbert – The Complete Series (1999)

    From Adam Dukovich:

    The voice acting is excellent. The characters all sound just as they would be expected to when reading the comic strip. Daniel Stern as Dilbert, Larry Miller as the clueless boss (who had to have been based off of one of Scott Adams’ bosses), Larry Charles as slacker engineer Wally, Kathy Griffin as Alice, the triangular-haired female engineer, and Chris Elliot as Dilbert’s sidekick Dogbert, not to mention a parade of guest stars, including Tom Green, Andy Dick, Jerry Seinfeld, and Jason Alexander. Put simply, this show had talent to burn.


    Five Measures of Product Manager Performance

    American idol judges

    Joy posted a really good article last week at Seilevel’s requirements defined blog, Measuring product manager performance on internal system products. Her post is a followup to an extensive and heated debate that happened last fall on the Austin PMM forum. It’s a great forum to subscribe to – a lot of experienced people with strong opinions and steamer trunks full of anecdotal data – and they don’t all agree. You get to see the coin from all three sides* with this group – it’s awesome.

    Continue reading Five Measures of Product Manager Performance

    Tyner Blain in the Google Toobar

    Google toolbar logo

    Tyner Blain can now be viewed thru the Google Toolbar!

    In the top of the sidebar (on the right) is a link to automatically add Tyner Blain to your Google Toolbar. As of today, it is only supported for IE users, but Google is now a supporter of firefox, so they’ll be adding support for custom toolbar buttons soon.

    Who are we doing this for?

    • Windows users who read Tyner Blain outnumber Mac + Linux readers (combined) by ten to one.
    • Over 30% of Tyner Blain’s readers use Internet Explorer
    • According to Forrester, only 6% of internet users use RSS
    • Fewer than 10% of Tyner Blain’s traffic is thru RSS feeds
    • Note: Firefox tips at the end of this post!

    How does it work?

    There are two things you get – first, easy access to the most recent posts (including a short synopsis), and second – the ability to search Tyner Blain for keywords, text, categories or whatever.

    How do we install it (in 4 clicks or less)?

    1. First, click on the link in the sidebar
    2. Google may ask you to install the latest toolbar – if they do, click on the link shown here
    3. Then select “Add” from the dialog that Google presents
    4. Confirm that the Tyner Blain button has been installed
    5. That’s it. 4 clicks. 3 if you have the toolbar already installed.

    But I don’t use IE

    Then subscribe to the RSS feed -> Copy the URL from any of the links in the red box and add it to your newsreader.  Do this by right-clicking on the link, then copy the link location in firefox (or copy shortcut in IE), then paste it into your RSS reader
    right click

    Or – use the firefox Livelinks capability to create a dynamic shortcut in firefox

    Or – if your newsreader autodiscovers a feed from a website, just enter http://tynerblain.com/blog – the newsreader will find it for you.

    Subscribe and enjoy!

    Describing the Software Development Process

    Peeling an onion

    Describing the software development process

    Software development involves determining what to develop, documenting this decision, determining how to develop it, and actually developing it.

    • How do we separate these very different processes so that we can talk about them?
    • How do we staff a team to accomplish them?

    We present a framework for describing this process in terms of layers of activity. Many people use pyramid analogies, which show the magnitude of effort in each layer (lines of code versus lines of requirements, for example). Many other people use inverted pyramids to reflect the importance (or impact) of work done at different layers (a sentance defining a strategy has more impact than a line of code). Some people show PERT diagrams of waterfalls or pretty circular arrows charts showing iterative lifecycles, or any of many good analogies.

    We think of it as an onion.

    When describing any software, we can discuss the software at any of multiple levels of abstraction. The heart of the onion is a secret to those who never cut onions – they only see the outside. The center is strong, but if you aren’t used to it it can make you cry.
    Different people in an organization will discuss a software solution at the different layers. It isn’t because they are unable to discuss at a different level, it is because the level they discuss it at is most germaine to the decisions they are making. A developer will make decisions that are much more focused than a CIO. And a product manager will apply policy decisions at a different level from either of the others.

    We will describe out framework in terms of different layers of abstraction. We’ll start at the inner level, or smelliest part of the onion and work our way out to the skin. We’ll move from the concrete to the abstract. From the implementation details to the goals.
    The layers of abstraction

    1. Implementation. The actual code that is written and running. The user interface that is presented. The tests that are included in a regression suite. We do what we’re asked, in the way that we’re asked.
    2. Design. The architectural description of the implementation, UI and test suite. Design decisions define much of the reality for developers – good design decisions make implementation and maintenance easy. Bad design decisions can make for disaster.
    3. Requirements. Different processes will use different names for these. In a process that uses structured requirements, this is the functional requirements, user requirements and business requirements. These can be captured in an FRS, SRS, or PRD (but please no, not all three!).
    4. Market analysis. The problems or opportunities that express potential ROI opportunities. These can be captured in an MRD.

    How do organizations handle this?

    Most software is driven from the top down (4,3,2,1) and it can be like peeling an onion. First identify a value prop. Then figure out how to achieve that value in software. Create a design that will work, and implement it. Each step is peeling another layer from the onion.

    There are exceptions to this rule – many startups have a “this is cool, what can we use it for?” mindset. Also, more mature businesses will often task someone with leveraging existing assets – which means “find out how to make more money from what we already have.” There are absolutely good examples of this both in software and in hardware. But that’s really not what software processes target.

    Different people in the organizations have different responsibilities – they tend to operate exclusively at one layer of our framework or at most two layers.

    Wearing one hat or two?
    Looking at common roles within companies or on projects, we often find people doing two of the jobs in our four-layer framework.

    • Design/Implement is a common pairing (combining 2 & 1). Architect/developer is a practical and common senior position. The skills required to design and implement are complimentary – one is expressly a superset of the other.
    • Market/Spec is another common one (combining 4 & 3). A product manager often plays both roles (outbound and inbound are the industry jargon terms for “focus on the market” and “focus on the product”). There are synergies between understanding what problems need to be solved, and identifying what problems need to be solved with software.

    A bad idea is combining the roles of “decide what to do” and “decide how to do it”.

    • Spec/Design is rarely done intentionally. We’ve done this once, and succeeded only because we rigorously separated the two roles. Technically, I played a Spec/Design/Implementation role, while managing other developers and building a relationship with the clients. We do not encourage staffing people with this combination of responsibilities. It is no more natural as juggling while swimming.

    Final thoughts

    There are four roles in our framework, from identifying valuable opportunities to writing great code. It is a good idea to combine design and implementation responsibilities in a senior person on the development team. We would have avoided our requirement writing mistake if we had done that on our previous project. Combining inbound and outbound product management responsibilities makes sense for smaller teams and exceptional individuals.

    Asking the same person (or the same document) to define both what software should do and how the software should do it is a bad combination for any but the most nimble switch-hitter. Shakespeare would qualify as a nimble switch-hitter.

    [Update: We’ve created a few followup posts that talk about these topics in more detail

    ]

    How to manage data when writing requirements

    weather report

    Don’t trigger a data explosion with enumerated requirements.

    Managing requirements can be tricky when it comes to managing data (information). The difference between a good approach and a bad approach can add up to hundreds of hours of labor over the life of a project.

    In our picture, we show the weather forecast for several cities. Imagine we were writing requirements for a weather-forecasting page. We need a way to identify the cities for which we will show forecasting information. Imagine there is room on the page to show the forecasts for only fifty cities.

    Solutions to this problem have evolved over the years. Good solutions have even been around for a long time. Unfortunately, too many projects stopped climbing the evolutionary ladder along the way.

    evolution chart

    Thag make fire
    Realizing that the developers would not have the business context to know which cities to show, our simian spec writer documents all of the information. He meets with the stakeholders and they give him the list of cities. After eating a banana, Thag enumerates all of the cities for which we want to display weather information.

    • […]
    • The system shall show the forecast for Paris.
    • The system shall show the forecast for Perth.
    • The system shall show the forecast for Prague.
    • And so on…

    While this does show good use of tools, Thag fails the abstract reasoning test. We’ve talked several times about not putting implementation details into the requirements. Marcus wrote a good article about this on his blog a short while ago. This would be putting data details into the requirements. And it introduces a maintenance headache.

    Sir Chauncey heats the boiling oil

    A little abstract reasoning makes the maintenance of this solution better. Sir Chauncey realizes that there is a list of cities that he can represent as data. When interviewing the stakeholders, he discovers that the list of cities changes every 3 months – good data. We’d hate to have one of our serfs hard code the city names into the application. Sir Chauncey now only has to write one requirement

    • The system shall show the forecast for the cities listed in ListOfCities.dat.

    This is definitely better. Someone maintains the list of cities, and the development team is free to decide if they want to update the code every time the cities change, or dynamically access the list at runtime. Sir Chauncey hasn’t specified the implementation, and has also not saddled himself (or anyone else) with a long list of requirements to maintain. What our armored analyst has not done is understand why the fifty cities are on the list in the first place.

    Kevin flicks a light switch

    Kevin knows that there’s a reason why we have a list of citites. He just doesn’t know what it is. So he interviews the stakeholders, and eventually finds out that the marketing department is in charge of the list. Kevin discovers that the list is the fifty cities with the largest estimated number of AOL subscribers. The marketing department has targeted AOL users for this forecasting page.

    Kevin also realizes that the limit of fifty cities is actually an implementation detail – and finds marketing’s true requirement – “as many cities as we can show without additional user interaction.” Our rennaissance requirements manager is able to write a more enlightened requirement.

    • [R1] The system shall show the forecast for the cities with the largest number of AOL subscribers.

    Kevin also writes a constraint.

    • [C1] Additional user interaction will not be required to display the city forecasts. {This constraint affects requirement [R1]}

    Kevin’s development team, like Sir Chauncey’s, can choose to access the list at run-time, or they can even calculate the list dynamically. And because Kevin wrote a constraint instead of ever creating a list, Kevin’s developers can even design a screen that shows more than fifty cities (they may choose to implement an interface that changes the list of cities every few seconds – like the Hertz Gold board, or a forecast-ticker that scrolls data across the screen, or anything else).

    The evolution of our data requirements

    What we’ve learned as the science of requirements management has matured is that we should not enumerate requirements when we can apply an abstract idea to describe them. In this example, the notion of each city as data is the abstraction. We’ve parameterized the data and simplified our requirements.

    We’ve also learned to keep digging until we understand the true requirements, and not just the enumerated results of the hidden requirement. In this example, the hidden requirement is that we care about the largest AOL subscriber populations by city. We recognize that the list of cities is not an arbitrary list – there is a reason for including each city. So we document that reason.

    Top Five Ways To Be A Better Listener

    headphones

    Effective listening skills yield great requirements

    The better you are at listening, the more people will want to tell you.

    If you’ve ever watched The Actor’s Studio, you’ve heard over and over that the most important skill in acting is reflective listening. A marriage counselor will tell you that step one in solving your problems is to listen. Consulting 101 will reiterate the importance of active listening. Presentation trainers stress good listening skills. Dale Carnegie – listening yet again. Sonar technician. There’s a pattern.

    Listening is not enough, however – just being a good listener is important, but not sufficient to assure success. Good listening skills are critical to interaction, compromise, partnership, discovery, and almost every significant component of working with others. And requirements management depends upon having the effective listening skills to learn from other people.

    Interviewing is the primary requirements gathering process in any project. Getting feedback from users and other stakeholders is important to validating and prioritizing requirements. Communicating with people is critical to success in managing requirements. And listening is at least half of communicating.

    With good listening skills, you not only hear better – people say more. Apply these tips to become a better listener.

    Top five ways to be a better listener

    1. Use active listening. This is my desert-island* listening skill. When we confirm actively that what we just heard is what the other person just said, we avoid a lot of mistakes – and it encourages that person to tell us more. It also tells our speaker that we are “getting it” and she isn’t wasting her time. This is also known as reflective listening.
    2. Have attentive body language. Smile. Make eye contact (not creepy stalker eye contact). Square your body so that you’re facing whoever your talking with. Don’t fidget or look impatient. Don’t check your watch (if you have an important meeting – tell the person before you start talking that you need to check the time – or that you’ve set an alarm on your phone for five minutes before you have to leave). And whatever you do – don’t answer the phone if someone calls. Nothing sends a stronger “what you are saying is important to me” message than sending your phone to voicemail without checking who the caller is.
    3. Ask questions. Get clarifications to statements. Ask the person why. There are several questioning techniques we’ve talked about before, and they help us with eliciting requirements. They also give feedback to the speaker that we are interested in what they are saying. Anyone who’s lectured or presented to a room of dead fish knows how tough it can be to not get any questions.
    4. 100% focus. Don’t multi-task when you’re listening to someone. No instant-messaging or answering emails. Don’t get distracted by the urgent matter that just came up. We can reschedule the meeting for when we aren’t overwhelmed, or we can take a couple minutes to compose ourselves, focus on the meeting/interview, and relax. We can review our notes about what we want to talk about before we go in – and get our head in the game. If we’re going to talk to Tony for an hour – it’s Tony’s hour.
    5. Use non-verbal attends. Nod your head, validate what you hear with a quick glance to the expert in the room, clap your hands, grab a pen and scrawl down some notes. Any reaction to a particular point made by the person speaking is a non-verbal attend. If you give the person this positive, genuine feedback, they will open up, become more comfortable, and talk more. And therefore tell you more.

    *In an earlier post, we talked about our desert-island requirements management skill – communication.

    Take this poll or we’ll shoot this kitten

    Really cute kitten

    [Ed: If you read Tyner Blain via RSS you have to visit the site to vote in the poll. Also, we’ll use a camera.]

    An earlier post on CRUD use cases started a fantastic debate (both public and private) about what it means to write great software, and if it’s even possible to write good software when we start with requirements. This leads to a discussion of the value of requirements driven development (RDD). If you search on Google, you’ll see at least one whitepaper from every RDD-application vendor. Not exactly impartial.

    So, here’s a poll. Coerced, maybe. Impartial – probably. If you’re new to the Likert scale – the unlabeled numbers (2,3,5,6) just serve to graduate the space between the “well described” positions.

    Our poll asks how you feel on a McLaughlin scale about the impact of requirements on the greatness of software.

    1. Metaphysical dependency. Great requirements enable great software (required, but not sufficient for greatness)

    2.

    3.

    4. Take it or leave it. The benefits of requirements balance out the cost of managing them – no more, no less.

    5.

    6.

    7. Inverse dependency. Requirements suck the life out of our team and our project – we’d be better off without them.

    The poll:

    Thanks for voting! And add comments if you want to explain your vote.

    Top Ten Use Case Mistakes

    broken glasses
    The top ten use case mistakes

    We’re reiterating the top five use case mistakes from Top five use case blunders and adding five more. For details on the first five, go back to that post.

    There’s also a poll at the end of this post – vote for the worst mistake.

    1. Inconsistency.
    2. Incorrectness.
    3. Wrong priorities.
    4. Implementation cues.
    5. Broken traceability.
    6. Unanticipated error conditions. The error conditions are explicitly called out in a formal use case as exception courses. When we fail to think about how things can go wrong, we take a bad situation (an error) and make it worse by leaving our users with no reasonable way to deal with the errors.
    7. Overlooking system responses. When people use computers, the computers respond. It is a cause and effect relationship – and ideally one that is predictable and comfortable to the user. Reading a use case should be like watching a tennis match, with activities being performed alternately by the user and the system. “The user does X, the system does Y, the user does Z…”
    8. Undefined actors. Novice and expert users have different ways of using an application. Different design tradeoffs will be made to accomodate for these users. Understanding the domain of the user can also be important. Imagine a calculator application – the use case of “get a quick answer to a calculation while doing something else” will be very different for a loan application officer than it will be for a research scientist.
    9. Impractical use cases. We have to remember to validate with our developers that they can implement the use cases, given the current project constraints. As a former co-worker is fond of saying – “It’s software – we can do anything” which is true. But considering the skills of the currently staffed team, the budget and timeline for the project, and the relative priority of the use case is prudent.
    10. Out of scope use cases. If we don’t define the system boundaries, or scope of our effort, we risk wasting a lot of time and money documenting irrelevant processes. Starting with the specious argument – although our user has to drive to the office in order to perform her job, we don’t include her commute in the scope of our solution. An online fantasy sports league application would certainly include a use case for picking players for individual teams – it may or may not include researching player-statistics. Knowing where the boundary is will prevent us from defining and building undesired or unnecessary functionality.

    More discussion on common use case mistakes

    I liked this article by Susan Lily on use case pitfalls. Susan goes into more detail on out of scope use cases(#10 above), where she talks about defining the system boundary in UML use case diagrams as a means of helping to avoid out of scope use cases. She also encourages using a standard template for use cases (Inconsistency – #1) and proposes a minimum set of criteria for creating your own templates. She provides a good argument against CRUD use cases – in a nutshell, they do not represent primary user goals (but rather tertiary goals).

    At one point she proposes a compromise of including low-fidelity screen mockups in use cases as a means to make them easier to understand and more efficient to communicate. I disagree with her here – this is at best a slippery slope, and more likely the use case equivalent of my requirements documentation mistake. Because images can be so powerful – even the simplest screen design elements will provide design guidance (Implementation cues – #4) to the developers – IMHO, it is unavoidable.

    We’ve added a new feature to Tyner Blain – polls on individual posts! We’re going back and adding polls to the most popular posts, and including them in many of the new ones. Each poll can have up to 7 entries – if an item isn’t displayed, hover over the up or down arrows and the list will scroll. If the text for an entry appears truncated, hover over it with the mouse and the text will scroll. Vote early and vote often, and thanks for your vote!

    Poll: The worst use case mistake is

    If you selected ‘Other – not on the list’ please add a comment and tell us why!

    A requirements documentation mistake

    monkey with banana

    Learn from an early mistake of mine

    At a previous employer, the first time I played the role of requirements manager (technically, program manager – with responsibility for the functional spec), I made a bunch of mistakes – this post is about one of them.

    The setup

    We were engaged in a high-pressure, tight-deadline, under-staffed project with a lot of visibility (Fortune 100 CEO visibility). This custom software development project was expected to yield savings for our client in the $100 million (USD) per year range.

    We had a novel situation in that we staffed the development team a week before I was pulled off another project to join this one. There were 20 brand new, fresh out of college developers, on the opposite side of the planet, chomping at the bit to actually have some work to do. We did not staff any senior developers / architects on the project for almost six months. We did have experienced technical consultants on site at the client, managing all of the systems integration and deployment and logistics issues. They were not available to make product development decisions.

    The project was one that was designed to improve both management accounting and sales decision support processes for this large company. Understanding the objectives required relatively deep business domain expertise. Our development team did not have that expertise, and our business consultants were already overloaded with rainmaking and pathfinding activities.

    We were building and deploying this software with an incremental (not waterfall) deployment strategy – with anticipated quarterly rollouts. Once we got our arms around the amount of effort required to implement the first delivery, we had to adjust our schedule – the first deployment of anything was going to take six months.

    The mistake

    There were many mistakes made by many people. The one we’re talking about today has to do with documenting requirements at the right level of abstraction.

    I can’t share the particulars of the underlying requirements, so I will describe the user interface. We had a user interface that allowed people to view a large set of data – the results of a complex OLAP query, presented in a concise form to the users. A user would commonly want to view this rolled-up data for multiple items, and would specify parameters by which they would want to filter the results for display. It was important to these users that they be able to sort the results (presented in a table) by any of the columns in the table.

    Our development team (with a development manager, but no senior developers) was given a set of functional requirements from me, and a screen mockup from one of the HCI designers on the project. The requirement stated that “users must be able to sort the results by any column.”

    With what we all know today – I already messed up, because I specified implementation details in the design (“column” should have popped up on the radar, and arguably “sort”). What I should have done was specify that users are able to view the results in any order based upon the displayed parameters.
    The next paragraph will have you rolling your eyes, smacking your forehead, or shaking your head.

    Our developers were not satisfied with “sort” as a requirement – it was too ambiguous. I complied with their requests, clarified alphanumeric sorting, and thought I was done. In the next cycle of clarification (remember, our development team was working twelve hours time-shifted from our on-site team), I had to agree with them that there was no room in the UI to present a sort-by control, and suggest that they sorted by clicking on the columns. The next day, I was asked to specify if the sorting was ascending, descending, or both. The day after that I was asked to decide if the user would be able to restore the results to their original sequence. The following day, I clarified the desired default sorting order, and what to do in the event of ties (use the most recently sorted column to determine ties, or sort in order from left to right on the page, or something else).

    My mistake – I answered all of the questions, documented the default sorting paradigm, linked all sorting requirements to that component, validated (and often gathered) all of the answers from other technical members on the team, confirmed with end users. We had a very consistent and unambiguous definition of how to interpret a requirement that users be able to sort a table by any column.

    Hindsight is 20/20

    Remember – this is a $100 million (ROI) project. And we’ve got hours invested in defining and documenting how sorting should work. I definitely did not have my eye on the ball.

    What I should have done was defer to the “design lead” on the development team (who did not exist at that time), while escalating the issue with our management team until someone was appropriately staffed in that role.

    I never should have put that level of detail or effort into the documentation of sorting functionality. It bloated our functional requirements document and blurred the line between requirements and design (crossed it, really). There were many examples of this type of detail, specifying a lot of user interface behavior and algorithmic interpretation of requirements.

    We also had an extensive data dictionary explaining the specifics of all of the management accounting requirements – gross profit margin, trailing twelve months revenue, oligopoly metrics and a hundred other terms defined in detail. This, it turns out, was a very good thing – people were still using that data dictionary years after our initial project was completed.

    This highlights both the critical need for someone to design an application, and for people to understand the domain in which they are being asked to work. Both the intimate domains and the telescopes… posts were inspired by memories of this experience.

    How else could I have avoided this mistake? Tell us in the comments.