I am sure people running small companies have come across this problem.
Being a small company, there are often pressures of deliveries and projects are usually of smaller scale usually upto max. of 4 man months. For such small projects,time to market is very much essential since bagging the project very much depends on the time estimated for completion apart from pricing. I have been an ardent follower of "documentation" and my belief is that documentation strategy should be followed atleast keeping ISO as a benchmark until we reach somewhere near.
We already have a project methodology in place, however during estimation it becomes very difficult to include documentation in the estimate since the estimated time of project increases and im sure all know that documentation takes almost double the time required for coding.
My question here is,in such cases,how can one work towards in organizing a better project implementation methodology for smaller companies. As I mentioned earlier, we can stick by stricltly following the standards, however we then stand to lose any potential client due to longer estimated targets. Is there a better way to work towards this and estimating in a better way, else we stick to "No documentation" and dont get anywhere in the future as far as growth is concerned.
Im sure all have started small,how do we proceed ?
I sense a certain amount of frustration with the impact documentation has on the schedule.
There is no doubt that "quality" will impact cost and time and it is often the hardest thing to sell.
From a sales point of view, you need to be able to sell more than just time and money. Hopefully you have a product/service with features that are different to the others. Your quality component is part of that service.
A possibility is to offer a couple of options. The first your full system, the second on with reduced quality, but a fee for later improvements and bug fixing.
From a Quality Assurance point of view, to often people see the documentation as something that adds time to the project, not reduces time from the project. This may or may not be reality, but it is most certainly perception.
Keep looking at the bigger picture.
Documentating knowledge is a key to continuity by reducing dependencies on key people. If not, why not?
You should be able to learn from past documents and thus reduce your time. If not, why not?
Through peer review of documents you increase peoples knowledge and identify errors earlier. This should lead to the improved productivity. If not, why not?
The time you spend in getting the design right can realy save you in time and money at the end. There is no doubt it is cheaper to fix mistake found on paper than fix the found in UAT.
If we are documenting for the sake of documenting then we have missed the point.
It is definately possible that we can over document. In most cases this is not the case.
If you realy want to improve, you have to first ensure perception and reality are the same. Take some measures of different projects and be honest. Ask how many issues did we find and when? What would of happened if we had of identified these earlier, or later?
A final tought. It safe to say most people are in business to make money. This is different to making sales. If you make a sale that cost you more to deliver that the sale price, you are not making money.
Even if we were not to include documentation in the costing and were to do it at our own cost,the cost of developing the project is higher and there are no profits.Even if it were to recover the development cost initially, it can still be fine.But small companies cannot afford to be rigid about their approach when vying for projects in such a competitive market these days.
Everyone intends to grow and growth comes if there is a flow of concurrent projects.SME's usually have smaller teams of 1-3 size for handling projects with 1-2 PLs looking after 1 or many projects.
>>Ask how many issues did we find and when? >>What would of happened if we had of >>identified these earlier, or later?
In the midst of small size projects, specifications usually change although they are frozen before design,functional changes do happen since there might be some added functionality which requires design change.Although the functional change may not be very large, it may require design changes and therefore has the possibility of affecting other modules. In short, a small but important functional change may cause a change that may take an extra week to do.Now small companies do not have the advantage of telling its client that you pay more for this, since the client expects that this small change is within the existing scope of work and he may go with a slightly extended time frame.It is not correct to expect the client to understand the technicals of the project. In such cases the scope of work increases and the cost of project is not justified since time spent is more than expected.
I mean such cases and much more arise for smaller companies but one cannot stick to his boots saying that you pay more or we wont do it.The requirement is ours and we need to do it else the loss is ours.
Kapil -- To a large extent, the management of small concerns, with limited resources, is an issue of multi-project management. In small orgs, or in multi-project environments in general, the biggest time sink is the lack of prioriy and the resultant reliance on "multi-tasking" to keep things moving. This must be avoided to any extent that you can.
But even within the context of a synchronized portfolio, as you suggest with your concerns about changing specifictions, the planning and promising process for the individual efforts have to respect uncertainty and variation while at the same time being simple enough for clients to understand and see as credible, especially since I suspect that for the kind of organization you're talking about, clients are resouces on a number of tasks in your efforts. And there is no tougher resource to try to manage than the customer.
Hi All - This is very interesting, as I was recently in a meeting with the CIO of a large company, and we discussed the challenge he currently is experiencing, which is how to effectively manage the "400 hour project," which is the way he describes smaller projects. Large projects seem to require (and it is justified) signifant amounts of documentation and a tremendous amount of structure to be run successfully. However, how does one effectively scale down the 4,000 hour project methodology and structure for a smaller, "400 hour" project? Just a thought to let fellow members know this is a challenge not only for small companies, but for large ones as well. Saving Changes...
Frank WintersPhotographer and ConservationistSandwich, Ma, United States
Kapil,
In your methodology, is it clear what documentation is needed, when it should be developed and what the purpose of the documentation is? In my experience the best documentation is developed throughout the lifecycle to support the entire process. The worst time consumer is the documentation process that comes after the system is designed and built. This is too late to be effective. Your question does not specify what kind of documentation you are concerned about -- but --if you have a lifecycle that includes high level requirements, conceptual design, in some cases a prototype, a functional spec and technical specs -- and if you use coding methods that are as self documenting as practical -- once the system is in integration testing almost all of the documentation is complete. The user docs should have also been developed along with the system so that user testing can test it as well. If you build documentation development into your lifecycle you get a system of high quality and a complete set of documentation quicker than by any other method I can think of. This is true for projects of any size, I believe. Please let me know if this makes sense and if not what is problematical in your environment.
I am working for a small organization which has to establish a formal process on SDLC. I am trying to establish some process. Would like to know if there is a template for functional specs, tech specs that can be used as a starting point Saving Changes...
