Post implementation

Finally you have moved the customer application into production and the users are tracking their mission critical information. No major issues need to be resolved and no bugs are being reported (for the moment). So one might be asking if it is time to sit back and smell the roses or is there still more work to complete for this project. While it might be nice to kick back in the easy chair and take a breather, there are a few key details to be covered before you can completely relax. At Geeks and Gurus, for example, we get together to verify all went well for the customer, to verify the internal processes set up for software development at our company were optimized, and to discuss ideas on how to leverage the recent success to bring more business our way.

Some developers believe all the steps outlined in a development methodology must be followed to the letter. This is far from the truth and definitely does not apply when it comes to this part of the deployment phase. The rest of this chapter offers some suggestions on what you can do after the application is in production. Feel free to pick and choose what works for your project. Some of these items have no purpose when implementing a 30 minute bug fix, others are mandatory when completing a full-fledged development cycle.

Post-mortem review

One of the keys to doing a better job the next time is learning what you did well this time or how you might have missed the goal, partially failed, or even completely failed to satisfy the customer on this project. Learning from your mistakes is something you learn very early in life.

We believe the best way to start this is to do a self evaluation, a post-mortem review. Each staff member (as little as one, as many as all) need to participate in this evaluation no matter how much experience they may have or how much they participated in the project. The evaluation contribution will be heavily influenced by a number of factors including experience, length of service, type of work they did on the project, and how familiar they are with various processes involved with software development. There is no ‚“one- size -fits-all ‚½ list of questions for a project post-mortem, but here is a starting point that might generate more ideas of what type of information can be gathered from this evaluation.

Please answer all questions that are appropriate, provide specific examples:

• Overall, what did we do well?

• Overall, what did we not do well?

• Were the specifications accurate?

• How much of the original specifications changed during the construction/testing phases?

• Did the developers do unit testing effectively?

• How many bugs were reported by the quality assurance internal testing?

• How many bugs were reported by the customers during acceptance testing?

• Did we follow the implementation check list? What problems did we come across and how can we improve the check list?

• Which processes need improvement and how can they be improved?

• What was the customer relationship before the project started? How is it now that the app is in production?

• What obstacles were put in place by the customer, which were added by your teammates? What obstacles were not removed by management?

• What did we do that wasted the most time and how can we avoid this next time?

• What did you most like doing during the application creation and deployment?

• What did you really dislike?

• What was the one outstanding thing you learned during pair programming or code reviews?

• What types of metrics did we collect on the project and how do they compare to previous metrics from previous projects?

• Were there any heroics performed on this project that need to be recognized?

• If you were forced to vote one employee out of the company, who would it be? (okay, now we are just checking to see if you are still paying attention)

So developers reading this might be asking the question: now that I have all this paperwork filled out, what do I do with it? Read each and every comment made on the survey. Digest the key pieces of information, and then select a team of people to gather and discuss these findings. This could be one person or the entire team. Bring them into a room filled with food and open up the discussion. Throw the key points up on a slide and get the discussion rolling. Use this session to brainstorm. It is our experience that developers talk freely when they know it is in the interest of the company to improve (and they are pumped with free food). Keep the discussion focused on the positive and make sure all the points key to improvement are noted.

These points also need to be written down and published to the entire staff so all can benefit from the discussion. Other items to note are proposed changes to company development standards, development processes, administrative processes, items in the employee handbook, customer change request forms, the company brochures /portfolios, and the Web site.

There is nothing more demoralizing in a company than spending time on something like the post-mortem, and then have nothing done with the results. We experienced this more times than we care to count in recent years at very large companies and smaller ones. It doesn ‚ t take too many of those to get folks rolling their eyes anytime something like this is planned, and resenting the ‚“window dressing ‚½ that tries to make the company look like it ‚ s progressive and ‚“on the ball. ‚½ It becomes a joke and more damaging than if you do nothing at all.

Customer follow-up

It is always a good idea to get together for a meeting with your customer to do a follow up survey as well. We like to have these meetings at a neutral lunch site or occasionally at the customer ‚ s office. You can have a formal survey sheet for them to fill out at their convenience or can take it verbally while waiting for the lunch order to be delivered. This is a perfect opportunity to get a feel for additional business or see if they have business associates that could use your expertise in solving problems. Follow up e- mails to get the survey returned and occasionally keeping up on their progress with the software needs should be a natural process in your business dealings.

There are four reasons to follow up with the customer. The first is to make sure they continue to be satisfied with the application and that it meets or exceeds their expectations in the production environment. There is nothing better than using the application in the real world to flush out the issues not covered during acceptance testing. If there is one thing that gives us more business, it is picking up applications from new clients where the last developer or shop failed to provide acceptable customer service. Do you want your current clients to look at the competition for their next project or to take up the enhancements to the project just implemented? We understand, sometimes the answer is yes depending on the customer, but the majority of the time you want to retain your business.

The second is to determine how well you did in the customers ‚ eyes. No matter how cool or killer you think the latest version of the app is, it may not meet the customers ‚ needs. It may be something simple to fix in the interface that the user finds hard to work with daily. One of our favorite examples of this was a simple grid entry. We missed the SelectOnEntry property of a textbox in one column. It just so happened the entry was normally overwritten with new numbers and the customer was constantly highlighting the contents with the mouse before typing in the new value. One five minute fix saved them hours a week doing data entry. This feedback also improves your development processes at the same time as you learn common problems your customers reveal.

The review with the client also helps out in another important area, figuring out the separation of the bugs from the ‚“by design ‚½ features. How many times have your customers called up and said the system was failing to perform a certain way, when in fact it is working exactly as they specified just hours earlier? It is our experience the customers need to be trained over time on what a bug is (a true failing of a feature not meeting the requirements) and what an enhancement request is. These reviews with the clients over a period of time help in establishing this difference.

The last reason for a post implementation meeting depends on how well the implementation and review have gone to this point. There should be no surprises at this point because you have been communicating all along. If it has gone well, this is the perfect time to ask for a letter of recommendation. Having positive testimonials on the company Web site and in the company portfolio will benefit future business opportunities. Most customers we worked with are more than accommodating .

Bug tracking

A perfect world would not have applications released with bugs, but the complexity of software today sometimes makes it almost impossible to do so. Some customers are shy about reporting what they think are bugs because they feel they have done something wrong to break the program. Others are going to pull your chain every time they find something wrong.

Tracking issues assists you in a number of ways. First, it betters the software you deliver to the customers, which in turn improves customer relations. Second, it provides you a list of things to work on for the various clients. Third, it provides the developers with a training mechanism for better development and testing techniques.

Fatal error bugs, the unexpected ones or the ones your customers find ways of producing, are fairly easy to track. Using the new TRY ‚ CATCH ‚ FINALLY , the object ‚ s Error method, or a global error handler expose a chance to collect specific application state information. Typical information we collect in our error trapping includes: the date and time the error occurs, the error number, the program or object method, the user login id, line number, the MESSAGE()

when it crashed, code that caused the error, the results from AERROR(), the call stack, LIST
MEMORY , LIST STAT , hardware configuration, the contents of Config.FPW, the environment settings, information about the various datasessions, information about all the active forms, and any user comments. It is important to provide a mechanism for the users to transmit the collected problems. Options include a report that formats the information collected. Another option is to print the report to PDF format and attach the PDF file to an e-mail and have it sent to your support e-mail address. The most recent idea we have is to transform the error information tracked in the error table into XML and have the XML sent via e-mail. The advantage of this method of transfer allows you to import the information directly into the support database.

So what do you do for the non-fatal errors? This is the kind of bug the user reports that allegedly does not meet the requirements or when the application fails to operate as they expect. It is important the user specifies a number of key elements. The elements we like to have reported are the exact steps to reproduce the error, what was observed , what was expected, additional comments, version of the application, the date the error occurred, and who is reporting the error. Additional information that can be helpful in these cases is the machine configuration. The same mechanism to transport fatal errors can be used to transport user reported issues.

Back at the bat cave you need to have a mechanism to track reported bugs. There are a number of ways to handle this including pencil and paper, a Word document, or more likely a software package dedicated to tracking bugs. Doing a web search reveals more than a dozen different bug tracking solutions. The BugTrackingSoftware topic on the Fox Wiki links to more than a half dozen available products. Visual Studio 97 (with which VFP 5 was included) includes a solution called Anomaly Tracking System (ATS) written in Visual FoxPro ( Figure 8 ). Visual Studio 6 includes a web version called ATSWeb. One nice thing about being database developers is you can augment the ATS products or build a solution that meets your needs if a satisfactory solution cannot be found. Some products like IssueView ( Figure 9 ) from a company called IssueView.com has both a desktop component (based on a SQL Server or MS Access database) and an Internet component, which uses Active Server Pages with full, built-in e-mail notification.

Figure 7. BugCentral.com is one example of a Web-based bug tracking application.

Figure 8. Some bug tracking packages like Microsoft ‚ s older Anomaly Tracking System have just a desktop component.

Figure 9. Several bug tracking packages like IssueView have both a desktop and Internet component.

There are other Web-based options that can be used including the new Customer Service Center from F1 Technologies ( makers of Visual FoxExpress), BugCentral.com (based on VFP and WebConnect, see Figure 7 ), and Steven Black ‚ s Wiki (another VFP and WebConnect implementation). The advantage of using a Web-based bug tracking application is your customers can directly enter in reports, geographically diverse development teams can access a common set of reported bugs, and customers can access reports to see the status of reports they made as well as reports from other users.

Microsoft products automatically send statistics back to Microsoft via the Internet whenever a GPF or other serious error occurs via the Dr. Watson Error Reporting. Are we the only developers in the world that get some pleasure each time this happens and hoping some Microsoft Web server is getting bombarded with the same reports? There are many ways to get the reports programmatically via e-mail, a Web service, and faxing.

Once a method to track bugs is implemented you need to evaluate the reported errors and alleged bug reports rapidly . It is important to determine which are real and the priority assigned to the issue. This sets the order the bugs are to be corrected. The reported issues determined to not be real bugs might be a change in requirements or something that needs to be addressed in training. Some reports are questions to be addressed in the Frequently Asked Questions (FAQ) list.

We have evaluated a number of solutions over the years and always found something in the products lacking. This does not mean you will, but it is uncommon to find developers who are completely satisfied with a canned solution. This usually leads developers to create their own solution.

Developer review

It is important to meet with the development staff to make sure they are working towards the goals of the company, the goals of the customers, and their personal career goals. All too often developers wonder what the management thinks of their performance. We have always believed a performance review should never reveal any surprises. It should be nothing more than an open discussion of the state of the projects, to establish new goals, and to find out what the next aspirations are for the developer.

Take this time to have peers recognize the good contributions a developer made to the project. Also have them provide constructive criticism. You might learn from the feedback something that helps you determine the share of the bonus pool (discussed later), determine internal training opportunities, and see what new techniques have been learned.

Post release party

Large projects, small projects, super successful projects, and client saving projects are definitely worthy of a party when teams exceed customers ‚ expectations. This is a good place to hand out bonuses and other reward mechanisms. You do not have to wait until the project is complete. Sometimes it is good to do a mid-stream gathering just to break up the stress that can build up during long development stretches. We find inviting customers to a get together is a great way to build partnerships.

These parties can be held a local eatery, as a barbeque in a backyard or local park, or right in the office. Just take the time to schedule a break to reward people for their hard work. Take a moment to verbally express the fact you appreciate the hard work the staff (and clients) are doing to accomplish the goals established.

Bonus pool

There are simple concepts of keeping people happy. Make sure they have adequate salary, decent benefits, current technology, good projects, a friendly atmosphere, and a fridge stocked with their favorite beverages. One way to make people walk out the door and get a job at the competition is to overlook their value to the organization. When people exceed the expectations you have for them, you in turn need to exceed their expectations in the complete compensation package. One way to do this is to give a bonus to the people who made it all happen by exceeding expectations.

Plan in advance what the bonus pool can be for service over the call of duty. Do not reward people equally unless they contribute equally. Reward for their contribution. If one employee does the nine-to-five and others work a boatload of overtime, make sure the people working longer are not working inefficiently. If others are working effectively and still put in the hours to make the deadline, make sure they are appreciated. Also, make sure those with families understand you appreciate the sacrifices that the families have made as well.

You can also be creative. Cash is not the only mechanism to reward the staff. For instance, if you have a developer who is a space geek you could send them to SpaceCamp for a weekend (hint, hint to the author ‚ s partners ). Sending the staff (and family) on a weekends away at a nice resort is a great way for people to recharge their batteries before returning to work. One of my favorite ways to reward people is to grant them more vacation time. Top gun salaried developers typically work late into the evenings and on weekends; why not give them back their time without any additional taxes to pay? ( Consult your accountant to see if this is okay in your particular situation.)

Single developer shops need to make sure they take care of the proprietor as well. This is so often overlooked when you have to run a business day-to-day. Make sure you take a cut of your spoils and keep the boss happy.

Do not underestimate the value of the employees . A long time ago, way back in the 1980 ‚ s I worked at Burroughs, at the time the third largest computer manufacturer in the world. This was my first big paying job out of college. I jumped right from a small consulting company I worked for during my last year in college to the big time systems management group as an Associate Systems Analyst. I was still wearing the rose colored glasses when it came to viewing the corporate world.

Along came a multi-billion dollar merger. Money was flying as two 5 billion dollar companies merged into one. Our group was tasked to merge the corporate systems. A project plan was assembled in November with a completion target date of June. This was an aggressive schedule to start and we were immediately put on mandatory overtime (without overtime pay). On February 1 we were informed we needed to have our system up and running in production on April 1 ^st (2 months earlier than originally ‚“planned ‚½). This meant it needed to be in the test environment for acceptance testing March 1. Management promised we would be rewarded for all our efforts and that they knew what it was going to take to accomplish this.

We had meetings at 5:00 every afternoon to see what the developers would be doing that evening. Then the managers headed for the golf course.

I worked over 100 hours of overtime in February alone and we implemented the system on time, with very few issues. Months later I had to walk into the Directors office to find out what happened to the bonuses we were promised. He just bought a fancy new luxury car and a huge house valued at 5 times what mine was worth. It was apparent where the bonus pool was distributed. He finally gave in to our ‚“concerns ‚½ and threw a dinner party at a local restaurant. That evening he handed out checks to the developers for $125.00 (minus taxes, I saw less than $100). This was less than 21 cents an hour for my overtime effort over the length of the project. Guess where my loyalties went after this? Do not make this same mistake.