Formalizing the Software Development Life Cycle? 27
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?"
"Only" problem? (Score:5, Insightful)
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!
tweeners (Score:3, Informative)
I worked for a company that had a project group. Although I worked in a different division, I won't let that stop me from making broad generalizations.
I think there is another group of companies out there: Those that can manage well some of the time. Just enough to be able to sign on the dotted line, that is. The company I worked for was able to codify all of the requirements into contract form, so whenever the client started acting all goofy we only had to pull out the "Sure we can do that, we'll have our lawyer start amending the contract!" card. That goes a long way in reining in squirreliness.
Of course, that group had the hardest time making any money.
Re:tweeners (Score:2)
It's merely a strategy for dealing with those who can't manage their own projects.
True, that it's a strategy that will keep the service provider from losing much money on the deal, but it isn't one that is likely to keep the customer happy.
After all, the central tenet of the philosophy is "once they've signed the bottom line we'll do *exactly* what it says or send in our lawyers to do the talking".
I'm not surprised to see your closing sentence though. That the project group had the hardest time making money is not at all unusual. There are exceptions, but project work is difficult and high liability work. I've seen literally millions of dollars in bills written off because the fees were uncollectable from the unhappy client.
Why so many small firms aspire to this work is a mystery I've still not plumbed.
BTW, I may be coming off a long term contract at the end of the month, so anyone who needs C++/Java/Python/Web services/grid/petabyte scale data warehousing help should drop me a line. rkw at objenv.com
Re:"Only" problem? (Score:2)
One little problem here: the staff augmentation market is dying a violent death. A resurgence in that market segment is not in the cards at this point. Your consulting firm will either get with the project work program (for real, not just on paper), or it will fold.
Good luck.
Ask Joel (Score:4, Informative)
Ask Steve McConnell (Score:3, Informative)
There's good resources on the Construx web site too.
Resources [construx.com]
Steve McConnell's Wacky Web Site EULA? (Score:3, Insightful)
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 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.
If I Could Shave Time in a Bottle . . . (Score:4, Funny)
I cannot squeeze 70 hours of work into one day.
Lessee . . .
I don't know about you, but I'm wondering what you're doing with the other ten hours of your day!
Re:If I Could Shave Time in a Bottle . . . (Score:1)
Forget about the IEEE spec (Score:5, Informative)
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 [joelonsoftware.com] and Painless Functional Specifications [joelonsoftware.com] 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 (Score:5, Insightful)
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 (Score:2, Insightful)
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.
Wrong URL (Score:2)
Re:SCRUM/Other Agile methods (Score:3, Interesting)
Scrum seems to me, just at first glance, to be a sort of "hostile" development process, because of the way the whole project begins:I don't know about you, but being presented with a project in that way would be demoralizing, not to mention weird. Also, their explanation of why it works is weak:That's not a development methodology. That's just common sense. What I've read so far seems to boil down to, "It's a flattened waterfall cycle that the Japanese developed" and "it's a Rugby term".
Scrum sounds to me more like the sort of thing that you feed to corporate managers who read books like Who Moved My Cheese? rather than developers desperate (or even just interested) in cutting down and refining their development cycle.
At the very least, I'd go for a methodology that has actual printed books (e-texts are great for source code and learning languages, but lousy for the philosophy or process of programming, IMHO) that you can refer to with your back to a computer. Right now it looks like to learn about Scrum, you hire (a) consultant(s) to come to your business and teach it to you, which sounds like an expensive proposition to me.
Re:SCRUM/Other Agile methods (Score:2, Informative)
I think you've misunderstood. It's the opposite of demoralizing--the management is trusting the development team implicitly to get the job done. They are setting up the environment for the team, then getting the hell out of the way.
Check out __Agile Software Development with Scrum__, by Ken Schwaber and Mike Beedle. It's a real, honest to goodness printed book!
I'm not involved with Scrum, just a consultant/developer implementing a new
Re:SCRUM/Other Agile methods (Score:1)
If my boss really trusted me, then why, after I tell her how long I estimate it will take, etc., would she ask me to do it eight times more efficiently? If I really thought I knew those numbers, and I thought my boss would pull crap as described above, I would be tempted to double them all in advance. This does not sound like an environment of trust.
Use lightweight/agile methods (Score:4, Informative)
Re:Use lightweight/agile methods (Score:2)
approximated the XP process, but every XP-like
process environment I've been in has kicked butt
over the bloated, beaurocratic, unrealistic
process models of, e.g. Unified, or the hopelessly out-of-date and irrelevant (to OO environments)
waterfall models. Heavy process is only good when
predictability outweighs productivity. Maybe if
you get a DoD contract, that will be the case, but
the F500's tend to do everything in-house, so your
role as a small consultancy nearly precludes a
process-heavy model.
Re:Use lightweight/agile methods (Score:3, Informative)
Agreed! It worked for me.
I look at my developing as a tradeoff between
- time to delivery,
- scope,
- cost, and
- sustainability (including code quality, product reliability, developer morale, etc).
Traditional development fixes scope in a spec, and cost in a budget, and time to delivery in a schedule. If the initial estimate is poor, then sustainability takes it on the chin, generally by burning out the developers and shipping crappy stuff. Managers promise that they'll make up for it "later", which really means never.XP turns that around by fixing time and sustainability, while letting the businessfolk play with cost (which they generally fix, too) and scope. Each week, the team delivers new features, albeit small ones. When the businessfolk decide that the pain of not shipping is worse than the pain of shipping, then the product ships.
This sounds like it could never work, but it does. Check out this programmer's diary [xprogramming.com] of a transition from a project like the OP describes to an XP project.
Re:Use lightweight/agile methods (Score:2, Informative)
Rapid Development (Score:5, Informative)
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.
Development methodology is not your problem... (Score:3, Informative)
I have worked for a large, multi-national consulting firm (business as well as IT), and the key factor that made us succesful was that we established very clear measures to manage the sales and delivery processes.
Specifically, we changed the reward system for sales people so they were rewarded for the profit of the job, rather than the revenue. This meant that it was in their interest to avoid under-estimating the project, and ensured the sales team remained involved after the initial sale was completed. As they are usually the people with the relationship with the customer and the insight into their requirements; often, they're also better at negotiating the inevitable changes to the project as delivery progresses.
We also established a system for measuring profitability of assignments, and individual's constributions towards that profit (based on somewhat arbitrary but totally transparent rules); again, individuals (the entire assignment team, not just the sales team) were rewarded for their contribution to that profit.
The outcome was that we ended up with less failed assignments caused by under-bidding, and a happier relationship between the sales team and the delivery teams - the sales guys worked with the delivery team to protect their slice of the profit pie, and didn't disappear the minute the contract was signed. The sales guys concentrated on opportunities that offered significant opportunity for profit, and typically looked for longer assignments rather than placing a couple of people here and there just to get the revenue figures up.
You might want to read David Maister's "managing the professional service firm" - most of these ideas are documented in that book.
Once you have worked those issues out, look at development methodologies. I'd recommend Alastair Cockburn's Crystal methodologies which may be easier to sell than some of the more radical Agile methods. To do business with major clients, you will almost certainly want to look at the Rational Unified Process (RUP, www.rational.com), which is almost a "meta-process" - you choose the elements you choose from a range of processes, practices and deliverables.