Formalizing the Software Development Life Cycle?

James asks: "My employer is a small consulting firm. Our owners have always tried to sell us as a solutions provider and tried to land project based contracts. Currently though our only truly successful business model is staff augmentation. I feel that our main failures in project based contracts is in our bidding and software development process. Our sales staff always seems to oversell our capabilities (not technically, time and money...I cannot squeeze 70 hours of work into one day). I want to better formalize our processes and was looking into the IEEE/EIA 12207 standard. Has anyone gone though the pains of formalizing to this extent their software development life cycle? If so, are there any tips, good resources to look to for insights?"

Comments

"Only" problem?

[rw2]

Your companies "only" problem is in bidding and managing the development process?

Isn't that the "only" product you offer?

Hiring qualified staff is reasonably easy (not dead simple, but something that's possible with a little diligence), so why wouldn't your customer do that themselves if you can't offer something more?

Here's the problem as I see it, and I worked for large, small and extremely small consulting companies/custom software houses, the project model of service offering is fundementally flawed.

There are two kinds of customer companies.

1) Those that run their shops well and run their projects themselves because they know their business and can augment staff with freelancers as needed to fill gaps in their knowledge.

2) Companies that can't.

Those that can you will never, or rarely, get project work from. They can do it themselves and not give up the margin to pay your overheads.

Those that can't you will not be able to complete projects successfully with because they can't manage well. That includes managing you, the service provider. It's a catch 22, your only target markets are the ones that, by definition, can't make use of your services effectively. Therefore you end up with broken promises, cost overruns and unhappy customers. You get these things not because anyone was dishonest nor trying to short change the customer, but because of the nature of the beast. You can, after all, lead a horse to water but you can't make him enter the product sub-ID into field 92 to facilitate regression testing on the backend.

I suggest that you convince your management that staff augmentation is a really cool market to be in and doesn't present nearly the headaches that project work does, but does present all the upside.

Well, there is one downside, if you abandon your failed project based business plan you will have to compete with me... Best of luck! :-)

Forget about the IEEE spec

[V. Mole]

It's not aimed at you (or rather, it is, in theory, but it's way overkill, and you'll spend more time doing meta-work than actually getting things accomplished.)

Instead, read some of the articles at Joel On Software, especially the Painless Software Schedules and Painless Functional Specifications He's somewhat arrogant, and he's a Windows developer (ex-Microsoft), but he's dead right on how to do basic functional specs and schedules. Once you've got something basic worked up, and have actually used it on a couple of projects, you can start looking at ways to improve.

Overpromising, Overbidding, and Risk

[Bouncings]

Your problem is common. Sales are desporate to make sales, and development staff get defensive. This is common of a development house like your own. I think you should read Managing High Intensity Internet Projects. It goes over some of these common problems, as well as some solutions.

Something else that minimizes risk is an evolutionairy development model. Your IEEE types will hate it, but the idea is that at any given time, the software can be deployed in a short period of time at whatever level of functionality there currently is. It simply minimizes risk by letting the users walk away from the project without getting "burned" by not having a product at all.

Rapid Development

[greenhide]

Rapid Development by Steve McConnell is an excellent book with case studies and descriptions of a variety of development cycles that you can use to get your projects through.

I'm guessing when you say that your main problems are bidding and software development, you mean:

Bidding is usually too low and doesn't cover costs, or is perceived by clients as too high and they don't bite. Unfortunately, there's not much you can do to control how a client responds to a bidding process. Ideally, you bid once you have a clear idea of all the work that will go into the project; if you can display just how much work it will be to the client (all the different use cases, all the different interfaces that will be involved, all the testing and re-testing that will be required) they may be more understanding of your bid -- they won't feel they're being ripped off.

In the software development process, there are so many things that can go wrong. The first is that it takes too much time. (Or is over budget, but from my experience budget *is* time--a piece of software is purchased to reduce time, or additional people are hired to reduce time.) This generally occurs because there isn't a clear understanding of the scope of the project in the beginning. The other cause for taking too long is slow response from the customer on its needs.

The solution to this can be creating a non-working prototype that shows every screen and page that the program will use. This doesn't mean creating 26,000 screens if there are 26,000 records in the program. You create screens for one or two sample records (say, one for each major "condition", such as "Approved", "Unapproved", "Expired", etc.). You also create a screen for every entry form and a sample of each report that the program will have.

You show this to your customer and get their approval. Make sure that each form matches all of the fields that they want. Ask them if there is any information they would want to know that isn't on any of the reports or forms. Then you say to your customer, "Is there anything else this program needs?" If they say no, you say, "Okay, judging by x forms, y reports, and z interactive screens, we estimate that it will take at least n months and no more than m months, with a probable time of p months."

The customer is happy because you're giving them what appears (and is) a much more firm time estimate than something off the top of your head, and they understand the complexity and process that will go into the development.

The other advantage to this process is that it kills the other software development dragon: developing the wrong software (it doesn't do what the customer wants, and offers features the customer doesn't need). By developing a prototype of all the screens, you can do a "sanity check" on the software to make sure you have the same understanding of the final project as your client does. Also, once the prototype is built, you hopefully will not have any features that need to be added on mid-project.

I hope these tips work for you. They sure have helped me out. Keep in mind I've only used these for web development, but I'm fairly confident they will work equally well in other areas.