The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
Fog Creek Copilot

The Old Forum

Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Post Project Reflection

Background: My company makes an enterprise-class financial application that is heavily customizable. I am currently involved in a few project roll-outs and demos, and my perception is that things are not done as optimally as they could be. This is bad for the company in the long term, and especially frustrating for the employees who must put in extra effort to counter process-related inefficiencies.

I am thinking of proposing the following to my team members and senior management:

1. We should come up with a project lifecycle template that identifies and documents standard stages such as client prospecting, demos, requirements gathering, solution proposal, product deployment, and user acceptance test that will give every team member a clear view of at what stage of the project we are in, what will happen next, etc.

The different roles that people will play in each of these stages should also be identified.

2. Institute a tradition of post-project "reflection" on how things could have been done better.

My question: does anyone know of articles that talk about what steps can be taken to make things less chaotic while deploying customizable enterprise software?

I am not talking of dull, fat texts produced by the likes of SEI. I'm talking of *effective*, short proposals and insightful articles like Joel's Painless Software Schedules and Fred Brooks' No Silver Bullet that can be used to mobilize my team-mates to act.

Tuesday, May 15, 2007
Well, in my experience, you can't begin to do #1 until you've done a bit of #2.

The book "Project Retrospectives" by Norman Kerth is considered by many to be the bible for retrospectives. I've also found the book "Agile Retrospectives" by Esther Derby and Diana Larsen to be valuable as well.

Don't go for the gold ring on the first try. If it took a while to get into this situation it will likely take a while to get out. Look for ways to move the football forward a bit at a time. Once people see that things can change and are changing for the better, the process will likely speed up.

Good luck.
Tuesday, May 15, 2007
>Institute a tradition of post-project "reflection"
Most folks call these "post mortems." Part of the problem with them is that many folks won't participate accurately/honestly in order to CYA.

I recommend reading the "post mortems" over at gamasutra.
Peter Send private email
Tuesday, May 15, 2007
The current, less gloomy term is "retrospective". Yeah, how pc.

Instituting a culture of continuous improvement is extremely difficult and, yes, you may find the results of the first retrospective are disappointing. That's no reason to abandon them. The book on project retrospectives that I mentioned earlier has a number of techniques focused on building "safety" in the participants so they feel able to actively participate.

Where I work now, we conduct retrospectives at the end of each sprint/iteration, at the end of projects, and at the end of each month (to discuss general issues). Occasionally, they are duds but most of the time they produce valuable and useful feedback.
Tuesday, May 15, 2007
The last company I was at did post mortems after every release.They were of mixed value. Sometimes we acted on the results of the post mortem. For a lot of the, however, we could have simply taken the list from the previously release, put the current date on it, and had our results.

Unless you actually do something with the results, they are just a colossal waste of time because more often than not you will be rehashing information everybody is already aware of.
Bart Park
Tuesday, May 15, 2007
I'd like to look at the larger picture for a moment. As inefficient certain practices may be in a company, there may be legitimate reasons for those practices ranging from laws, rules and regulations to union contract demands. I have also noticed that many such organizations have "procedures" for managing changes to those practices.

For example, there may be an obscure requirement to... I'm just pulling a hypothetical out of thin air... measure the amount of time spent testing for defects so that it can be expensed as a line item. Not only do you risk breaking the actual accounting mechanism, you may incur some political wrath from managers who deliberately want a high bug count.

My advice is to first identify a manager or someone with political authority who believes in the value of making improvements as opposed to an "if it aint broke, don't fix it" attitude. You can do it yourself but be prepared to spend a lot of time negotiating, cajoling, and generally encouraging people to take risks. I think ultimately it has to be someone who can convince others that they won't loose their jobs following your recommendations.

Once you've found someone, the next thing to do is simply document what's being done, how and why. Creating a process flowchart with all of the arguably superfluous steps and giving people a chance to see the issues and point to a box and say "we don't have to do this", goes over a lot better than simply saying "I think process X is broken, let's do process Y instead."

In other words, first focus on getting people to acknowlege the existing problems, going out of your way to encouraging them to do so as necessary. At the same time, tact and diplomacy is called for.

I think post-mortems (or reflections) are a useful tool but ultimately they're only effective at the staff level. For the larger issues like developing a SDLC, post-mortems don't guarantee management buy-in, and you really don't want to define SDLCs by committee. As fustrating and tedious as it may be, I truely do believe simply documenting everything and asking management to sign off on those documents, is more effective.
Tuesday, May 15, 2007
Check out the new second edition of Alistair Cockburn's book, "Agile Software Development".  It has information on a relatively painless way to document processes and also a good example of an incremental "low pain" way to adopt new processes.  Email me if you'd like page/chapter references.
John Rusk Send private email
Wednesday, May 16, 2007

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
Powered by FogBugz