Sunday, January 23, 2005

Small Business and SDLC

The SDLC (Software Development Life Cycle) is not as attractive to smaller business and projects. The business dynamics between the two are very much different in many ways. Small business and small projects are low budget and need to react quickly. Since the small budgets and business have very limited resources there is a great need to compress the timeframe and detail analysis. Since the smaller projects have less of an impact and do not cascade multiple sites and millions of dollars the risk analysis and assessments are much more limited and easier to scope. Therefore that teams and recourses would be a few people doing most all the work.

As a small business every moment of my time is tied to a billable resources in which I am accountable in order to pay the bills and put food on the table. The needs of volume and scope of work is not as great as an SAP type project. To attempt a full formal SDLC process would be too costly for both the customer and myself.

In the stages in the lecture where there is a lot of analysis prior to proceeding on the project, your company is paying the tab for the evaluation as both the developer and the customer. In my case we are separate and one is paying the other for the analysis. In your lecture everyone is getting paid as being part of the big organization. In my case I would have to create and estimate for each phase of the project and the customer would have to sign off at each phase and pay.

If I am asked to create a simple program or utility that would take me several hours as I do now. It would greatly increase the time and cost using a formal SDLC. So a $1,000 project without SDLC might cost the customer $6,000 with a formal SDLC. If the customer knows it may cost $6,000 for a small utility, then there may not be a project and that would be zero dollars earned. Do that 100 times a year and one would have made far less with the formal SDLC than compressing the scale of SDLC or none at all.

So profitably for the vendor and cost saving for the customer with working on a small project would be a definite reason NOT to follow a full formal SDLC.

The SDLC is a very delicate engine that requires a lot of fine tuning and self discipline to keep it on track and working. It can easily break down if all parties are not participating equally. In some cases they do not and you have to be flexible to compensate for the absence of their effort.

The SDLC is usually driven by management as they are the ultimate responsible person. That said having been a consulting analyst working for a large company you can be pigeon holed into just one area and not aloud to work in multiple areas at once or gain additional experience.

On a large scale project where there is a budget and people get paid no matter the outcome for a larger organization, I agree that SDLC should be used and have no argument with the text and your lecture in that respect.

So the moral here is use the right size hammer for the project.

No comments: