Best Practices when extending a project

Question

I have to extend a web application for a customer, there is no documentation of the current app, no analysis and even worse, there is no technical support or management. The client gives me a list of his expectations and nothing more.

What's best practice to begin such a project?

Answer 1

Probably the thing to do is to start thinking like an IT department. Yes, really. The idea is to avoid the risk of breaking something in production and not knowing why. Suppose for instance that you started hacking a new feature into the live, production application and something broke. Now the application is down and the customer is breathing down your neck to get it fixed. That would be a stupid way to proceed, right? So don't do that.

It's hard to imagine exactly what the environment is like, but you say "no technical support or management." So there's a web application running on a server, and that's it? Is there a test system, deployment procedures, source control, etc.? I'll assume not.

Given that, here are some ideas for how to proceed.

Get Read-Only Access, or Snapshot the Production System

Get access to the production system so that you can poke around to see how things work. Be very careful not to modify anything. If necessary, see if you can get a snapshot of the system (say, a filesystem backup), and restore it elsewhere. That way you can poke around without fear of accidentally fat-fingering a command and breaking something.

Source Control

If the source code and configuration files for the system aren't in some kind of source control system, create one and start using it. Even if you're the only one working on the system, this will help you track your changes, and if something breaks, you can roll back to the previous version.

Backups and Restores

Is the production system backed up? If it isn't start doing it. Obviously, don't try a restore to the production system. But do try a full restore to an empty system to see if you can recreate a replica of the production system.

Test System

Now you should have a system that's effectively a mirror of the production system. (Notice that I've started to use terminology like "production system" and "test system".) You can now tinker with the test system without fear of breaking the actual running application. Depending on how big a project this is, you could do development and testing on the same system. Or you might want to separate them. You might even consider a separate staging system between test and production.

(Search for "developmestuction" on thedailywtf.com if you want to read horror stories about mismanaged production environments.)

Analysis, Documentation, Development

Now that you have a test system, you can study it and write up some documentation for how it works. The goal isn't necessarily to document the whole system, but to generate enough information for yourself so that you can implement the new feature. You can also tinker with things to see how they work (or not) which will assist with the analysis and development of the new feature.

Testing Procedures

Now that you have a test system, perhaps with some new features added, how are you going to test the system? You need to make sure all the existing stuff works as well as the new features. Generate test data and automated tests if possible. If tests are manual, make sure you have a full set of actions scripted to test all the functions, e.g. create record, modify it, print a report, delete, etc.

Deployment Procedures

Now that you have all your code under source control, how do you put it into production? This also could be fully automated or a scripted set of manual actions, such as:

1. shut down application server
2. rsync files from staging to production
3. restart application server
4. smoke test (connect to web page to see if it works!)

Make sure you write down the rsync command or put it in a script or something. Getting it wrong could cause a catastrophe!

Summary

This might seem like overkill. Maybe it is. It depends on how big and how critical this system is. It can certainly be scaled down to be simpler if the risks aren't that big. But I can't overemphasize the need to think about testing and development separately from production. I've heard some amazing war stories about how somebody was tinkering with the production system and caused days of outages costing millions of dollars. I also can't overemphasize the importance of source control and deployment rigor. There are many other war stories of how somebody got something "working" on the production system, and the change never made it back into the source control system. The next time they deployed, the change was undone, things broke, and nobody could figure out why.

Anyway, good luck with this!

EDIT: clarified the first paragraph so that it's clear that it's talking about making changes directly to the production system.

Answer 2

In addition to information given by @Stuart Marks, you need to clearly define your responsibilities and your customer responsibilities. For example, your customer should allow for time to test your work and they should make payments according to some agreed schedule. Maybe the customer has to pay for hosting fees and other project related fees. Also, you should negotiation with the customer when and how to close the requirements window. You can't build one page then keep on changing it until the customer is happy. Figure out a way where you can tell the customer that this requirement does not belong to this release.

I invite you document the requirements, even in a simple document and read it with the customer to confirm the requirements. Make sure the customer understands what you will not do and what you plan to do. Most importantly tell them the cost and expected time frame. Include the risks you may face because of the current shape of the application.

Although not so nice, one has to identify what courses of action should be taken in case you and your customer don't agree, this includes resorting to arbitration, penalties, etc.

In short don't make assumptions and don't make your customer make assumptions also, specially about high level issues. Make every thing clear from the get go.

Answer 3

Depending on the scope of your project there are several points that need to be taken into account:

1. First thing first, planning. You should discuss with client your needs of application analysis and production support that probably you are going to implement. Setting up clear goals and expectations with client will ensure that there is no assumptions on what you are supposed to deliver.
2. Create development and deployment environments to support this application (Dev, QA, Staging, Production). By now, you should be having Dev and Prod, however do not underestimate importance of QA and Staging environments.
3. Set a time to create technical documentation of the project and convince the client that it is in there best interest. (There is always say that, what will happen if bus will run over me, one day?)

Answer 4

Fast-Tracking, Rapid Application Deployment, Rapid Deployment and many other euphemisms started appearing on the project management scene a few times ago. One can't really argue with their objective - speed up projects and therefore reduce cost.

General

1. You can have good

2. You can have fast

3. You can have cheap

But you're not likely to get all three, so Pick the Two that are most important to this project!

• Define project correctly, and do a Postmortem at each major milestone and after completion

Planning

• Without a plan, your project will be impossible to control

• People who must execute a plan should be involved in its preparation

• Use a Project Notebook to fully document a project - proper and accurate documentation is an important aspect of project management best practices

• Project plan should be signed off by all stakeholders in a meeting. Use a Change Order form, signed by affected stakeholders, to record significant changes to the project.

• BEWARE SCOPE CREEP!

• Mission statement should be developed for larger projects before goals and objectives are established.

• Satisfying the customer(s) of a project must be a primary concern.

• Objectives should be written out and placed in project notebook

• Objectives should contain actual calendar deadlines rather than being specified as "within x months"

Estimating Time and Cost

• Padding is legitimate to reduce risk, but should be done above the board

• An estimate is not a fact

• Reduce time available for a person to work on a project to allow for meetings, breaks and other interruptions

• Use chart-of-accounts to track labor costs.

• Record time daily to ensure accuracy.

• Gantt chart is most useful to see who is responsible for which tasks.

Scheduling

• Scheduling considers both duration of tasks and sequences in which work must be done.

• Break work down only to level needed to develop an estimate sufficiently accurate for intended use.

  Don't plan in more detail than you can manage.

• Bar chart = Gantt Chart

  Note: Bar charts do not usually show interrelationships of work, thus do not permit easy analysis of impact on a project if one activity slips

• Software can show how vacations and holidays will extend working times in order to assess their impact

Organization

• You must consider your own Organization Structure when planning and staffing your project.

• Hierarchical structure has serious disadvantages for running multi-discipline projects.

• Matrix is almost synonymous with project management because of its advantage in dealing with many disciplines.

• Success in matrix requires very good interpersonal skills on the part of all managers

Project Manager

• Look for a leader, not just a manager. People skills are important.

• Negotiating skills and flexibility will be important attributes. No project ever goes exactly according to plan and the PM has to negotiate the adjustments.

• Problems "go with the territory" and must be resolved. Avoiding conflict and technical problems only lets them fester and build.

• Communication skills are critical. PM will often have to bridge a gap between technical and non-technical stakeholders. And credibility is always at stake

• PM really has to be "everybody's friend...and nobody's friend" in order to lead the project to the desired conclusion.