All software projects face a major obstacle to their successful completion: hidden requirements. No matter how carefully you plan and design your project, customers will always introduce new and changed requirements right up to the point of deployment.
I use the term "hidden" instead of "new" when referring to late requirements because, in most cases, the requirements were there all along. You just weren’t aware of them. I also like the term hidden because it puts you into the correct frame of mind for dealing with the problem: You need to work at uncovering these requirements as early in the project as possible.
The truth is, you will always have to deal with some degree of late requirements, and in many cases, you can’t put them off to a future release. Critical requirements can pop up at the most inconvenient times, at least from a frustrated developer’s point of view.
|
This article will give you techniques for digging out hidden requirements as early as possible, thereby increasing the chance of your project’s success. I’ve organized the main points into specific recommendations that you can apply today. These recommendations apply equally to the independent contractor and the corporate staff developer. In a way, this article is a lesson in project management, but not the kind of project management you can express with Gantt charts and resource loading, so don’t go to sleep on me yet. No, a large part of what I’m going to tell you about is the part of project management I like to call "herding cats," which is trying to get all the participants in the project working toward the same goals. |
Recommendations for Finding Hidden Requirements
|
Put Yourself in a Flexible Frame
The typical IT response to hidden requirements is to avoid them by enforcing rigid development cycles with prohibitive change control practices. That is not the path to a successful project. Hidden requirements are real requirements, and failing to address them means failing to satisfy the business reality that they represent.
I’m not suggesting you embrace "feature creep," as it is sometimes called, but rather adopt analysis and design practices that expose hidden requirements early in the development cycle.
So how do you do that? I recommend that you approach the problem from several angles. You can go a long way toward exposing hidden requirements by digging into the business and political realities of the environment in which the software will function.
Every business application must contribute to the goals of the business it is designed to support. In my prior articles on software design, I stressed the importance of recording the goals of the project and the business rules that it has to enforce long before you attempt any coding.
However, extracting business rules from the organization can be difficult, and many developers lack the communication skills and interest needed to chase them down. Developers usually begin the project with the rules they have and are frustrated when additional rules are introduced after they have something to demonstrate. This "coding to spec" approach is fine for a junior developer who is given a specific task to accomplish, but it doesn’t work for the technical lead who has to develop those specifications in the first place. Bridging the gap between business and technology is an art. That’s why good technical business analysts get paid the big bucks.
Business Reviewers
One way to approach the problem is to follow recommendation number 1: Involve business reviewers in the project as early as possible. A business reviewer is a person who may or may not work directly on the project, but who will be expected to bless what you are doing. Often, your project cannot be released into production until these people sign off on it.
Okay, that rule sounds easy, but you would be surprised how many times important reviewers are left out of the mix until they notice what is going on or someone finally thinks to include them. This situation can be loaded with hidden requirements.
One way to identify potential reviewers is to consider your project in the context of the four major business functions: Marketing, operations, finance, and legal. You are likely to work pretty closely with the marketing and operations functions during the normal course of your project, but don’t forget to make sure that finance and legal see no difficulties with what you plan to do.
For example, if your application has anything to do with the collection or disbursement of funds, you can bet finance will be interested. Likewise, your legal department will be interested in any offers or disclaimers that affect your legal obligations to customers.
Milestones
Nothing is more frustrating than having your project delayed or canceled because someone important was unaware of the project’s details until near the end. Recommendation number 2 addresses that problem: Hold milestone meetings at critical transition points in your project. A transition point is any point in the project’s development where you have something to show and are about to start another major effort to build upon it.
Don’t make the mistake of viewing your project as one long development period between the receipt of business requirements and the delivery of a product. Break the development up into milestones, and invite all business reviewers to verify that you are still on track at each milestone.
Most importantly, identify the people who can delay or cancel your project. Make sure that these people are present at every milestone meeting. Be sure to address every objection and question immediately or as soon as possible after the meeting. You want these people on your side. You should make an effort to be cooperative, responsive, and responsible.
I want to stress the point that milestone meetings are not status meetings. By all means, have regular status meetings among the active project participants: Just don’t expect your business reviewers to attend every one. They will be bored with the detail and resist future invitations, sometimes right when you need their feedback the most.
Instead, milestone meetings punctuate critical points in the development cycle where the work you are about to do is dependent upon the work you have just completed. Hold them at points where you have something to show that demonstrates whether or not you understand the business requirements.
Policy Assumptions
For the political angle, consider recommendation number 3: Do not build unconfirmed assumptions regarding company policy into your project. If features or side-effects of your project have policy implications, be certain to get management approval before you incorporate them.
Sometimes, you have to delay development of certain business logic until you get an answer. Developers hate that. Most will figure that they get the basic idea and fill in the blanks as they go. They don’t realize that their assumptions, and design decisions related to those assumptions, enforce company policies that did not previously exist. This is a recipe for a rewrite.
The trick is weeding out the policy making assumptions and getting management to accept or correct those assumptions.
You can usually identify policy issues by the fact that they represent how the business interacts with its employees or customers. For example, your project might include a page that accepts product return information. If you make the original order number a required, validated field, you have effectively created a policy that says returns must be accompanied by an original receipt. That is a policy decision that should be made by management, not a developer. And changing it later will probably affect your user interface, your business logic, and your database schema.
When you do find a policy assumption, push it back for management review as soon as possible. In a busy organization, it may take weeks (literally!) to get a final answer. I’ve sent email that came back to me with a forward/reply thread that was 15 messages deep because my original question had to work its way to the top of the organization for a decision.
It is the nature of policy decisions that upper management usually has to get involved. You don’t want to make wrong assumptions about something with that potential level of visibility.
Programming in Context
The people most affected by your software are the people who have to use it on a daily basis to perform their job. Your software can have a significantly positive or significantly negative impact on their ability to do that job.
If you want your users to see your project in a positive light, follow recommendation number 4: Design your project with consideration for the context in which it will be used. Users are much more positively disposed toward new tools that improve or complement their work flow. Conversely, they will resist anything that makes their job more difficult.
I’ve seen too many developers who believe that it is the responsibility of the users to just use whatever they are given. That’s a dangerous and irresponsible attitude. Users will ultimately determine the fate of your project. If users consider it "unusable," your project will be discarded or replaced, which won’t do your professional reputation any good at all. In house developers could be looking at a pink slip and independent consultants at a lawsuit. I’ve seen it happen.
Unfortunately, users often fall prey to the ego barrier themselves. They think the developer must know best, so they don’t offer much feedback until they finally have to use the finished product and discover its affect on their workflow. Then they offer all kinds of feedback, and not all of it good. This situation is terribly frustrating for the developer who carefully included a user representative in all of the milestone meetings and design reviews.
The trick to avoiding this feedback delay is to "take it to the streets." Take your design prototype with you to the user’s workstation, which for your user is a much less intimidating environment than a meeting room. If you have a demonstration program, so much the better: Let her run it from her computer at her own desk. Walk through her normal activities with her and observe how your software helps and hinders her experience. You may discover small changes you can make to the project’s design that will have a significantly positive impact on the user’s workflow.
Taking this approach has political benefits as well. Users react more positively toward projects that they contribute to than ones that are "shoved down their throats." Also, management will observe your consideration as a sign of professionalism and genuine desire to deliver something usable.
Cost versus Benefit
The last topic I want to cover relates to recommendation number 5: Make sure that you communicate the cost of change. Management frequently doesn’t understand what it takes to take a project from point A to point B. That is what they hired you to figure out. But they have a keen interest in what it costs to get from point A to point B.
Unfortunately, the cost issue is sometimes ignored on both sides. Management fails to ask what it will take to make a change, or the developer fails to sit down and really figure out what it will take. This lack of diligence robs management of the ability to make an informed decision regarding the value of the change. Many enhancements seem like a great idea until you discover what it costs to achieve them.
Always give your best shot at estimating the cost of change and report that information to management, whether or not they ask for it. If you see raised eyebrows in response, you’ll know you did the right thing. One way or another, you will be held responsible for an enhancement that took "way longer than it should have" to implement. Management has a figure in their head for what it will take, even if they never communicate that figure to you.
A common estimating error is failing to consider the cost of destruction. When you build an addition to a house, the new construction usually requires some amount of destruction. The same is true of software. If the software is already developed, you will probably have to tear it apart somewhat to integrate the new features. The cost of destruction is something management almost never thinks about, and developers frequently forget.
Change is Inevitable
Late requirements are not always preventable, and they aren’t always minor. Some of them are show stoppers. Learn to accept these changes as a normal part of the project lifecycle, but also realize that you have the power to expose many hidden requirements during the design phase rather than the deployment phase.
This article discussed several recommendations for avoiding design changes during the construction of a business software project. Hopefully, you can apply these recommendations to make future projects proceed more smoothly than in the past, with minimal change during the later phases of the development cycle.
