Slashdot Mirror
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?"
I can't offer input here, but I can suggest you ask in forum for the Joel on Software software management discussion/article site. Good stuff there, good people.
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.
"There are two types of people in this world. Those that divide the world into two types of people and those that don't." -unknown.
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.
Anonymous posts are filtered.
There's good resources on the Construx web site too.
Resources
Anonymous posts are filtered.
As someone said above, the formal standards (IEEE, DoD2167a, etc) are way too heavyweight and complex for your environment. There are many many books on methodologies, but for small projects (say < 10 people for 1 year) you will want something very lightweight. One thing that's fashionable right now, and actually works, is "Extreme Programming". See http://www.extremeprogramming.org for a starting point.
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.
Karma: Chevy Kavalierma.
Or rather, not your only problem.
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.
It's all very well in practice, but it will never work in theory.
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