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! :-)

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.

SCRUM/Other Agile methods

[mattc58]

Go to http://www.controlchaos.org and check out Scrum.

Agile methods in general are much more appealing to me. You really cannot control the modern software world with methods created for factories and the like, no matter how many thousands of documents you write.

Steve McConnell's Wacky Web Site EULA?

[Lumpish Scholar]

Steve McConnell is one of the good guys, and deserves the huge amount of respect he's earned; but I've really got to wonder about his web site's EULA:

By viewing, downloading, and/or using material from this web site you agree to be bound by the terms defined in the license agreement ... This is the License Agreement for Construx CxOne Basic (the "Product").... You may not use the Product as your organizational software process. You may not use the Product in conjunction with all or with multiple software projects in your organization, division, department, or company....

This appears to be describing, not only what you can (and can't) do with some evaluation software, but also with the information you get from reading HTML and PDF files on the site.

Words fail me.