SDA India is an online resource for Software, Development,IT, Architecture, Open Source, Mobile, Security, Databases, Delphi, C, OS, Asp, .Net, Php, Xml, Java

Congratulations – you've landed your first big enterprise client. Now you need to do what you said you'd do, and make everyone happy in the process. This article will show you how to use techniques for visibility and verification to do most things – setting up processes and systems, doing QA and acceptance testing, and requirements gathering. This article will show you how to use techniques for visibility and verification to do most things – setting up processes and systems, doing QA and acceptance testing, and requirements gathering.

Listening to the Voice of Reality

You've worked very hard at your consulting practice. Long hours, lots of coding, working with a wide variety of small and medium-sized clients. Maybe you've hired someone to help you do what you're not particularly fond of – User Interface (UI) design, maybe, or Extensible Stylesheet Language Transformation (XSLT) [1] programming, or Quality Assurance (QA). You've moved out of the cosy spare bedroom in your house and actually rented office space, not much, where you slapped your logo on the door.

Then one day, it happens. You meet someone at a networking event who knows someone who knows someone that needs a really sharp development team. You all meet together and you're given the low-down on the project. 8-month project, low to mid-six figures, Fortune 500 client, and the work will start immediately.

Are you interested? Of course you're interested! This is exactly what you were dreaming about. You close your eyes and think about not having to deal with the small fry and their tiny budgets and huge expectations. You can't wait to sit in a meeting with the big guys, where they send in not one or two but maybe three or four IT specialists along with cadres of marketing folks who are as Web-savvy as they are draped in chic clothing.

You put together a proposal, everyone signs off, and now it's time to get started. Just as you start the work, you hear that little tiny voice in the back of your head. It's screaming for you to put the brakes on, telling you that a big client isn't just a small client with a lot more revenue, that a big project isn't just a small project with a really far away deadline.

You need to listen to that voice, because that voice is right. I know. I didn't listen, and I got punished for it.

First Things First

Before you do anything else, take a few moments to consider the big project from the client's perspective. Do they care about budget? Not as much as you think. Big public companies and government agencies may be conscious of price, but they've already identified a problem, one that is probably costing them millions of real dollars (or in lost productivity) so they want the problem solved.

What they do care about is open lines of communication and your ability to scale. Let's face some harsh facts. Most big companies and organisations suffer from bureaucratic paralysis. They may be able to identify problems that need solving or hatch great ideas, but most of these get stuck in endless, mind-numbing meetings and involve more strata of stakeholders than you thought possible. Even simple decisions like who controls the budget or who gets the manpower to address the problem can mean endless meandering through red tape and politics.

So first and foremost, big companies prize vendors who can scale their operations, act decisively and quickly, and keep them up to date on what's going on.

Now, let's go back to you. You're probably a technical expert in a programming language, process, or knowledge domain. You've been a sole practitioner with a small staff, and you're probably used to handling all kinds of stuff: payroll, banking, rain making, programming, technical discovery, training.

Time for all that to stop. I know, I know, for many of you, it's a control or trust issue. I know, because I had them too. You don't trust anyone to do things like you do, because no one is better than you at this. You want to control what's going on; otherwise you fear that chaos will follow.

I'm not asking you to immediately trust everything and everyone. Distrust or trust all you want, but put processes in place that allow you to verify. As for the control thing, concentrate on controlling the future of your consultancy or company, and again, put processes in place that give you visibility – from there you'll have as much control as you'll ever need.

So stop focusing on trust; think verify. Stop focusing on control; think visibility.

Your First Hire

If you don't already have a project manager in place, then you'd better make that hire now. What to look for in a project manager? Someone who is as anal-retentive as you wish you could be, and who leaves a paper trail behind himself (or herself) that is a mile wide. Someone who will set up meetings, take notes during the meetings, send out minutes about the meetings to all participants.

Someone who will be the single point of contact between the client and your group. Someone who will control the client when they want to do an end run directly to your developers. Someone who will never quit making, refining, and collating lists of action items.

Do they need to have experience in your particular knowledge domain or a certification in project management? No, but these things help. The most important thing, besides attention to detail, is a fearless communication style, one that is thorough during the calm periods and calm during the stressful times. You want someone who can communicate easily with a client no matter how ticked off the client is about things, and someone who is not afraid to communicate bad news quickly.

Now, let's pause for review. Have you decided that this person should be you? Lean in close, so I can smack you. Your job is not project management. Your job is being the architect, the rainmaker, the visionary. The client doesn't need you to be the project manager; they need you to be the expert on your project. Every minute you're tied up in spreadsheets, GANTT charts, and typing up meeting notes is a minute you're not looking out for them.

Other Hires

If you're a small shop, you will need to hire a lead developer, someone who is the best technical expert you can find who can then own the details surrounding the technical work you do. No, you are not abdicating your role as technical guru, but you need someone who can execute on your ideas and vision. If you're the one in the technical weeds, you're going to get mowed down by something big you missed.

In many ways, this person will be the technical twin of your project manager. This person will be someone who knows the technology you're dealing with (PHP, Python, XML, whatever) inside and out, and shows a propensity to learn new and upcoming technologies. This person will lead your efforts in acquiring solid infrastructure and will follow your lead on the processes you set down.

Will this person be a coder stuck in his or her cave? Hopefully not. They should combine good communication with technical abilities—after all, you're asking them to take on a lead role. Yes, they will likely be the person who touches 80% or more of the project, but they have to have a strong head for delegating tasks that they don't have the time or talent to pursue.

If you already have a trusted right hand, then evaluate where this person is weakest. If you're pursuing a project with lots of XSLT requirements, for example, figure out if their expertise covers this domain. If they don't have it sewn up, figure out if they can learn it in time or if you need to hire someone on a part- or full-time basis to cover that base, or outsource it to a contractor. The same approach can be adopted for all other areas, such as QA, documentation, and training.

Another bonus to the technical lead: He or she can help you hire folks for other slots in the team, and be that person who can play devil's advocate when you've both been on your feet for 20 hours straight and you're not that sure if you're thinking straight.

Processes and Infrastructure

You've got a good start on your team, but now you need to put in the support struts. Do you have adequate processes and infrastructure in place to keep things moving forward?

Most small shops don't have much in the way of process or infrastructure, and sometimes for very good reasons. Some of you reading this piece may be shuddering at the very thought, but don't fear, I'm not advocating the entrenchment of an inflexible bureaucracy.

Remember what I said about verification and visibility? These are your watchwords. The most important pieces of infrastructure you can put in are a development server and a source code repository. You can place the development server on your own network, or you can arrange to host a managed server with a local hosting company. Owning this asset means that you have control over your development environment, and can make the changes you need to make—such as recompiling PHP to support your application's needs, or adding multiple databases—without waiting for the client's IT department to get around to it.

A good source code repository, such as Concurrent Versioning System (CVS) [2] or Subversion [3] (both of which are open source) can allow your team to grow and give all coders access to source code. This will become more crucial as the project proceeds. A good source code repository also allows you to run reports on who is doing what, and whether different objectives are met on time. Subversion and CVS, for example, both allow branching of code to test different approaches and flagging of releases so you can stage out your delivery of code.

Coding Conventions

Here's where we get to that part that makes everyone groan, especially junior developers. What does it matter if your tabs are set to two spaces or four? Who cares if we put the { on the same (or different) line from the if or else? Why should it matter that your method names and variables are camel-cased?

It may not seem like a big deal, but using the same style of coding conventions throughout your application, like requiring that all class files be kept in the classes/ folder and be named like page.class.php can be very helpful. If nothing else, it can keep everyone on the same page at 2:00 a.m.

I'm not advocating any particular style—that's your job. Pick an approach and stick to it.

Discovery

When you worked for those small clients, you got used to working with minimal or non-existent discovery documents. Sometimes all you needed was a short phone call to gather requirements, which you could implement shortly after the conversation ended. Or you got used to working with a simple bullet list of goals and deliverables, or some scribbled notes from a whiteboarding session.

Guess what? Those days are long gone. You have to document everything important. Notice I said everything important, not everything. It's highly likely that discussions you have over the phone, via e-mail, or during face-to-face meetings might amount to nothing at all, but you have to give the client visibility into what you're learning and allow them to verify what you gathered.

There are untold dozens of systems out there that purport to help you gather requirements from clients, encode those requirements properly (technical specs, Visio diagrams, wireframes, and so on), and get feedback and buy-in. I don't advocate any particular approach; in fact I've tried at least five or six different ways myself, with mixed results.

You have to find a system that works for you, your team, and your client. Rest assured that with longer enterprise engagements, you'll need to have an approach that:

• Identifies stakeholders and end-users
• Captures requirements from them
• Prioritises those requirements
• Encodes those requirements in such a way that the stakeholders understand them
• Verifies those requirements
• Communicates those requirements to the developers

Yes, this means that you might run through a series of documents during the discovery process. For example, you might have a questionnaire on project goals that gets a 10,000 foot view and identifies stakeholders. You might have another document that helps you capture interviews with those stakeholders, and a template that helps you identify end users of the application and gather critical data from them to fill out your use cases.

After this initial work, you might hold a large meeting with key stakeholders to report to them what you've discovered, using a PowerPoint presentation followed by a white boarding session that seeks to prioritise goals and functionality. Here's where a project manager in the meeting can be key—while you are working the room and the whiteboard, he or she is busy documenting, asking questions, and reminding stakeholders about budgetary and scheduling constraints.

Your final requirements deliverables might be a five-page business case, a separate page flow diagram of your application, and supporting use cases. Each section could have a little place where the stakeholders can initial and date to verify your findings.

Finally, you might want to deliver this same set of documents to your developers but then operationalise it by working with your lead developer to create a Unified Modeling Language (UML) [4] diagram of your application. We also take a note from Agile/Scrum [5] [6] and create note cards that describe each component of the system and then disseminate these cards to the developers responsible for those components.

Of course, every document you create gets placed into your source code repository. Any time any one makes a change to a document, the document's revision section is updated. So anyone can look into the document and find out what things changed when, who made the changes, and what is the current version of the document.

Doing the Work

Depending on your agreement with the client, you could be working in any number of modes. For example, you will likely have milestones that call for delivery of different components at certain dates. Or you may have to convert so many documents to Extensible Markup Language (XML) [7] by a certain date, or install a database patch by this other date.

In my experience, most clients, and this includes the most savvy stakeholders at the largest corporations, don’t know what they want until they've had a chance to look at it. No matter how much you document it, wireframe it, or describe it, there will be changes made as soon as they see it.

When it happens, don't be angry or frustrated. They are not trying to get you, nor are they trying to make life intolerable for you or erode your profits. It's just human nature. What you have to watch out for, though, is that the directives you're getting are coming from a canonical source. Make sure that you work your process. Involve your project manager. Have him or her create a written description of any modification request, especially if it originates as a call or vague email. Take the time to ask pertinent questions, document it all, and then present it to the chief stakeholders to get final approval.

Do you charge for every change that comes down the wire? That I leave to you and your relationship with the client. But if you follow the process of verifying and giving your stakeholders visibility, you won't get burned as often as you would if you just ran off and complied with every half-baked request.

What happens if you don’t take this approach, get lax, or just think to yourself that this little request can be taken care of quickly? Well, let me tell you a story. At one point in our first enterprise engagement, we had over 40 stakeholders engaged with us. There were so many channels of communication open to us that I decided to "help" my project manager by taking on requests.

It started innocently enough, of course, little changes here and there, but then suddenly we found ourselves taking dozens of requests every day, as more and more department stakeholders involved other people who were seeing the application for the first time. We got a request to do X, which was pretty easy and involved removing Y. Within two hours a manager in another group called to ask why X was in there when they had asked for Y.

When we explained that X had been requested, we were asked for details. Of course, the request for X had come in the form of a vague email, which I forwarded. The person who wanted Y talked to the manager of the person who wanted X and got X countermanded. So we took it out and put Y back in.

By the end of the day, the chief stakeholder called me and wanted to know why Y was in when the original specs called for Z. That was true, I told her, but a month before there had been a change order authorising the change from Z to Y. I did have that change order as a fax, which I faxed to her. It turned out that the signature on the change form was not hers—it was her assistant's who had been filling in for her while she traveled to a conference in a nearby city. Apparently, nobody had told her about the change, or she had forgotten (doesn't make a difference either way).

At this point, I came to my senses and requested that we a) stop work, and b) have a stakeholder meeting to sort it all out. I also suggested that I extract myself from the process of playing project manager, and that all stakeholders at the client company should use one channel of communication to speak with us to avoid this kind of chaos.

I can't make this stuff up.

One more thing—I prefer to work in an iterative cycle once the requirements are set. Whenever enough components have been pulled together and I have a chance to show them to end users or stakeholders, I do it. Why? Because they've paid me a lot of money, and they want to be sure that things are coming together. The more they see progress, the better they'll feel about the whole thing. (And as you'll see in the acceptance testing section, showing end users and stakeholders your work allows you to collect feedback early and build goodwill.)

Doing the QA Dance

On most small projects, your job is pretty easy. You code something up, put it in a development or staging environment, do some testing, show the client, who eventually approves it, and you launch it.

Those days are also over.

First of all, most enterprise projects will involve hundreds of thousands of lines of code (if not more), and have dozens of components, each with their own subcomponents. You have to have some way to QA all of this without killing yourselves.

The first step is to work from accurate requirements documents, use cases, and specifications. The second step is to make sure that you touch base with your developers on a regular basis (we have a standing meeting every morning to go over issues, and it lasts 10-15 minutes most days). With these two in place, you'll nip a lot of problems in the bud and get visibility over the spectrum of activities happening on the project.

If you're using a source code repository like Subversion, each developer can update their local libraries, work on their pieces independently and check them back in to your development server. There developers can perform unit testing—to make sure that their code does what it is supposed to do according to specs and use cases.

Once they're sure that their code is working okay, developers can perform integration and regression testing—does the module or component I'm working on play well with others? Did I just change something in a core library that breaks another module? Did I add an unexpected parameter that will break something downstream?

Throughout the process, you need a way to communicate and track bugs. Some organisations use spreadsheets, others use home grown utilities. I prefer Bugzilla [8], because it's free, puts your bug database on the Web, can be used to report on multiple parameters, and has some very good notification features in it. For example, you can set it up to notify developer Y if any bug that is tagged as Category A is ever entered—so then all your UI bugs go to your UI developer, and rules engine bugs go to the Java geek down the hall. You can set yourself up as a watcher and can get notified whenever bugs are created, change status, get closed, or other possibilities. (Do yourself a favor and put your project manager on watch lists too!)

Best of all, Bugzilla can be exported to other formats, such as Comma Separated Values (CSV) format [9], which can be pulled into a spreadsheet for use by your project manager. Furthermore, each time a bug is created, it has to be entered by someone with a username and password, so you can control who has the ability to issue bugs.

Any bug reports you get outside of Bugzilla shouldn't be ignored, of course. Instead, have your project manager enter them into Bugzilla, even if they seem silly. It's a trivial thing to go through and close bugs that are repeats or shouldn't be worked on by your developers.

Acceptance Testing

Seventy percent of all software projects fail outright. When considering the other 30% of "successful" projects, you find many cases where the organisations involved merely declared victory and shut everything down.

But why do projects fail? Missing, miscommunicated, or misunderstood requirements are by far the biggest reasons. Hopefully I've given you some tools to help make these problems go away.

A close second to all this? Lack of end-user acceptance. Why? Because rarely are front-line troops—the ones who will use your application—ever invited to stakeholder meetings. They never get to give any input. Their managers or outside consultants are the only ones you ever meet. Unfortunately, these people don't have the kind of visibility actual users of your system have.

Ignore the end user at your own peril! Most of the time, the stakeholders you're dealing with don't know you need to talk to end users at all. You're the expert, not them! Even if they present you with reams of documents in which they've covered every conceivable request from end users, request a tour of the office or plant floor. Meet some end users. Take them out to lunch. Talk to them early, see what's bugging them.

Spend an afternoon just hanging out watching what happens. How do their processes get them through the day? Where do their processes get in the way? Where do they put in short cuts to avoid bureaucratic nightmares? Does person A from this department do small favours for person B in finance to expedite work orders?

If you ignore the end user at the beginning of the process, if you don't talk to them upstream, you certainly will be talking to them at the end of the process, when you deliver the final application for acceptance testing and/or training.

Guess what? Those stakeholders who didn't give you access to the end users early on will be asking those end users at the end of the project what they think of the new application, and you'll be judged by what they say. Fair? No. But you didn't ask, and they didn't have that kind of visibility into your expertise.

Remember, no one can verify you're on the right track more than an end-user who is an expert on a particular procedure or workflow.

Okay, so you've either captured requirements from end users or you haven't, but now the day has arrived and you're ready to start acceptance testing. How should you go about doing this?

Request that the client provide at least two groups of end-users, roughly equal in size. You'll use the first group as a kind of focus group. They will get a live demo of the system in a conference room, projected onto a wall. Tell them they have been chosen to give their impressions of the application: what works, what doesn't, what's missing, and what's either wrong or needs modification.

With this group it's crucial to not get into the weeds, even if somebody in the group wants to see an example of the "workflow scheduler for legal notification" that they first requested six months ago. If you're lucky, you'll finish the meeting with several bullet lists you can then show your stakeholders and team members, so that any changes can be prioritised and built in to the development schedule.

With your second group, sit them down one at a time with the application. Sitting with them one on one helps you capture a precise snapshot of each user with as little bias as possible.

Tell each end-user that you're trying to figure out if the system was built to their satisfaction. Most folks in this situation will blame themselves for being stupid about computers when things go wrong, so tell them ahead of time that they are not being evaluated, the system is. You are there to see how they use the system, what buttons they press, how they use the system. Encourage them to think out loud as they work, even if those thoughts are negative.

Present them with a task list (from your use cases) and tell them to start. With any luck, the task list mirrors reality, but if it doesn't, and they speak up about it ("I wouldn't do it this way") make sure that you ask them to elaborate while you take lots of notes. (If you have trouble with this part of the work, hire an outside usability consultant to help with the acceptance testing.)

Under no circumstances do you argue with the end user. All you do is sit and take notes as they perform tasks. Don't give opinions, or value judgments. Try to work through each person quickly—if you take up too much time, you may make them anxious, impatient, or tired, any of which can throw bias on to your data.

Once you're done, collate every note gathered from this second group. Notice any patterns? Usually, if one person has a problem with a certain module, then others will have the same experience. If you have five end users in your study, and only one person had a problem with Module A, then you don't necessarily have a problem (unless, of course, that one person was the world's expert on what Module A is supposed to help her with).

If four or five in the group have a problem with Module C, you definitely have a problem, but don't assume that you have to scrap everything. Look through your notes. The answers should be there, especially if you encouraged folks to think out loud. Maybe they had a problem with Module C because the font was too small, or because three widgets they expected to be grouped together were scattered across the screen.

Don't start working on anything until you show your data to stakeholders. Verify what you've found and let them help you prioritise everything. Adding a widget or two to the interface might be quick, but may pale in priority to fixing the massive problems associated with the slow database connection.

When should you run acceptance testing? I usually run at least two sets, one scheduled about a third of the way through the project, and the second right before completion. This way I can get as much information as I can early on and a second set of data at the end to confirm what we know.

Summary

Congratulations! You've nailed down your first big project with an enterprise customer. But beware: big projects have a number of inner dynamics that make them very different from the smaller jobs you've gotten used to. Hopefully this article has shown you how to scale your operations, using the tools of verification and visibility to keep things running smoothly.