Self-made: managing the process of software development by small team of experts

Each organization has need to automate some particular processes. In the case the necessity to create some specific software is critical for the business, this software can be ordered for development in the third-party company. However, organization can often cope with the automation by it's own forces, with the help of small development team (one to three persons). The risk is that the management of the development process can be entrusted to people which specialty is not directly associated with activity of such kind – programmers, engineers of another area of expertise or managers not acquainted with the software development specificity. This could be the first experience of this sort for the organization. It is not less important through to provide acceptable standard of the process quality.

This article is based of my one-year working experience working on the project manager/developer position in the small telecommunication company. The main processes concerned with the software development are being examined, these that I managed to distinguish and formalize. I will try to make some basic suggestions that can be useful when managing software development projects in companies like this.

To make it clear, what we are talking about, first I will try to paint an overall picture of production in the sphere of software development and support in companies which profile is not directly associated with said activities.

Description of specificity of internal-use software development and support in the small company - not the software developer

1. Great number of tasks (more than half) is related to maintenance, support and modification of existing (legacy) software.
2. Tasks related to existing systems support are practically independent, can be solved in short time, but appear frequently and demand the real time solving.
3. The development and support is executed by a small group of specialists, often by the only person at all.
4. As consequence, there is no explicit division of roles in the process; the same person can work as a developer, analyst, architect, tester, system administrator, project manager etc.
5. In the majority of cases projects do not go beyond the scope of the internal use.

As consequence, the software development process in companies like this by virtue of objective causes is fairly rude. Many procedures either omitted or present in the simplistic form. However, even such process should be managed and the acceptable quality ought to be assured.

Common suggestions regarding the development process arrangement

1. Try to separate spatially, as much as possible, software developers and other specialists
   Modern approach to software development deeply appreciates the ease of communication. Without doubt, it is great when the developer needs just two steps to make to ascertain with the customer itself the way to resolve any problem, input data format or something else, but seating the sales manager and the programmer side by side, you will lower at least in quarter the working efficiency of the latter.
2. Prohibit whosoever, except the project manager from setting targets for developers directly
   The project is always likely to get out of control if developers fulfill such, even urgent orders. Requirements will not be registered, tests will not be performed, there will be on-the-run modifications, developers will be forced being under pressure to make too optimistic time estimations and will always feel themselves slow, because no one will know how much work they did.
3. Assign either the person or the time for discussing tasks
   The practice shows that development-support tasks appear regularly during the day, circumstances almost each time require immediate clarification. If you have two developers, let them negotiate with the customer representatives in turns, if you have the manager specially assigned to this — let him do this job. The problem is that administrative functions (like clarifying the problem circumstances and importance, contacting stakeholders) require immediacy, while thechnical request fulfilment, on the contrary, is more efficient when it is possible to focus on the problem for the continuous period. Incessant distraction of developer, besides the efficiency reduction causes another negative effect: the difficulty of adequate estimation of actual manhours. Meanwhile, not registering actual manhours developer loses skills to make right estimations.
4. Assign a separate telephone line to each developer
   Don't get developers involved in the secretarial work. Developers are often responsible and painstaking people, while managers with all due deference to them often have no time. Not understanding the nature of the developer's work they can without any hidden motive leave them a half of calls.
5. And in general, never under any circumstances get developers involved in the unskilled labour
   Of course, if you don't afraid to lose your developers. Remember that developer extremely appreciates his/her skills. Good developer will always get a new job, but it is doubtful whether you will get a new developer just like easily. In major companies with mature production process it is possible to replace one developer with another without considerable expenses, but in such small company what I'm talking about, the developer can be the only bearer of knowledge regarding operative applications, or their sole author.
6. Register developer manhours
   In the changing world of business, for example, in the telecommunication business, the number of tasks related to existing systems support remains roughly constant. Existing systems regularly require minor changes. As a result of development of new software, the number of systems to support increases. What a conclusion can we arrive at? The total number of tasks grows up with the lapse of time. So when the developer says that he/she handle his/her volume of work well no more, this is likely to be true. Hire more people or order the development and support of part of your systems in the third-party company.
7. Provide your developers with the opportunity to study and share the experience
   Being a chief you can not be abreast of all the latest changes in the world of software development. You can think that man that is already good in programming has no need to study anymore, that experience he/she acquires in process of everyday work is quite enough. But if developers will not be abreast of the latest technology developments, your software will become obsolete very soon and that will become a barrier to your market penetration.
8. After all, create a document describing a company organizational structure
   Whatever small your company is, this document is still absolutely necessary. At least the developer needs it to know with whom to contact on which question.

I cannot assert that this list is absolutely complete, and doubtless it is possible to make any other suggestions like, for example, to provide developers with all needed software/hardware. This is just that I make my suggestions concerning those areas only that caused the most number of problems during my work in company of this kind.

Formalizing the process

Wnen organization problems are solved up to the mark, you can concentrate on the development process.

It is unlikely to apply any heavy-weight process in this case, no doubt, and a literature on this topic will hardly be helpful, but it is worth to formalize existing process and make it more effective.

My opinion is that basic recommendation that can be made here sounds like «Just the essential and nothing additional». While you have the opporunity to start with the minor, formalize those procedures only that you can, and create those documents only that will be actually used.

It is most likely that you will distinguish the following subprocesses:

1. Managing requirements
2. Iteration planning
3. Functionality implementation
4. Managing and implementing support requests
5. Testing

At some stage even these subprocesses will be enough. Further in this article I will provide a more detailed examination for subprocesses that are related to process/project management and will try to make my recommendations on formalizing these subprocesses.

Subprocesses and project documentation

Managing requirements

The good and much more detailed and profound than this article literature on the matter exists. Here I will just describe the minimal amount of work that should be accomplished, at my opinion, to create the reproducible process of requirement management.

1. Identify requirements sources
   Such sources can be:
   • Managers of any level
   • Commercial staff
   • Customer service
   • Customers
   • Cooperate company representatives
   • Engineers from other departments
   • Developers themselves
   
   
2. Define who, how and when can propose software requirements
   There is no need to set the above-listed participants any limits like particular formats and means. Be ready what when necessary, requirements will be voiced verbally or by phone, will be sent by e-mail or by ICQ, and in that form what is easier for the person who speaks. In collecting requirements non-technical specialists and nonspecialist will participate. The main things to assure are following:
   1. To let the developer work without distraction (See common suggestions regarding the development process arrangement).
   2. To give all the participants to understand the fact the requirement is registered does not mean it will be accepted and implemented.
   
   
3. Participate in collecting requirements
   It can happen that for a number of reasons you will not be involved in the process of collection of requirements and will not have any information about meetengs and their results. You can work with concluding documents instead. This can probably happen if your primary position is developer and it is supposed that your task is to implement requirements, not to spend time on discussions. This can happen if your company has several remote branches. Anyway, try to convince your management that as a person who performs project planning and control you need to participate in such discussions.
   
   
4. Reqister requirements!
   As much this point is important as often it is neglected. Lets sum up one more time why it is necessary to register requirements:
   1. To confirm them formally
   2. To plan the work
   3. To check up the work
   4. To argue with a customer
   5. To train developers and users
   6. To have an ability to check out whether the application operates right after modifications
   7. To have an ability to substitute one application module with another
   
   
5. Register requirement sources
   It concerns as requirements as a whole so the requirement particular technical details. If the requirement or wish was accepted as a result of a discussion, register these who took part in the discussion. This makes it possible if necessary to find out reasons or details by asking directly that person who expressed the wish. In addition, you can analize whose wishes were taken into account, and whose were not.
   
   
6. Confirm requirements
   Assign persons who should confirm accepted requirements. Do not get down to the implementation till the requirements are confirmed. Make it a rule and never depart from it, or you will always remake the same functionality and remove just implemented one.

   In simple case, I propose the following format for the document that will contain confirmed requirements:

   1	2	3	4	5	6	7	8
   #	User Story	Comments	Priority (1,2...)	Realize in iteration #	Realize in version #	Man-hours estimated	Man-hours used

   Till the confirmation I used to store all the requirements in original form: as e-mail messages, notes in writing pad etc. I'll give more detailed view on how to fill in columns 4-8 in following items.

   Directions of advancement:

   1. To register all requirements, not only confirmed
   2. To keep the requirement versions and a history log

Iteration planning

1. Define the size of the iteration
   I always planned two-weeks iterations and, in my judgment, it is quite suitable size, because within two weeks it is possible to do not so very little and still to get feedbacks quite often to correct the process of development in proper time.
2. Estimate man-hours for the iteration
   Only do not try to schedule all the working time for the project activity. By my observations, even in the software development companies programmer's average occupation in the project hardly reaches 6 hours a day. The rest of the time is being spent on organizational tasks, business correspondence, information search in the Internet, building solution, installing updates or new vesions of software, or just conversations. In case of holding of more than one position I would not risk to schedule more than half the time for development. Thus, a rough estimate can be as follows:
   

   4 hours per day * 5 days * 2 weeks * 2 developers = 80 man-hours per iteration

   I hasten to remark it is not so little as it may seem.

3. Schedule the time for each requirement implementation
   Such estimations ought to be entrusted to developer, who can better than anyone imagine how much time it could take to implement each requirement. Without scheduling the time for the requirement implementation it is not possible to plan the iteration.
4. Register actual man-hours that were spent on each requirement implementation
   It can be necessary when analysing how accurate are estimations made by developers, how much could it take to implement any resembling functionality, and above all, it is a measure that registers practical man-hours of your development team per iteration. This is the basic figure that you should proceed from when planning the next iteration.
5. Define the procedure to determine which requirements are implemented within the iteration and persons involved
   It is useful to write the instruction which describes your software production process on the stage of iteration planning.
   Such instruction basic items can be as follows:
   1. List of persons who approve/endorse the instruction itself.
   2. General description of the document and its purpose.
   3. Process roles description (Customer, Developer). It is worth to specify who is responsible for which decision, and the general nature of interaction between actors.
   4. Step-by-step description of the procedure of interaction between actors.
   5. List of resulting artefacts.

   As before I recommend to include in this instruction initially only steps that are absolutely necessary. The key criteria should be certainty that you can ensure those listed steps will actually be made.

   The procedure should result in confirmed application requirements, distributed among iterations, with estimated man-hours specified and priorities assigned.

6. Identify person concerned
   It is important to find out as soon as possible who represents each class of users when collecting requirements, who assignes the priorities and so on.

   It is very important to identify persons are to be notified of new version releases!

   There is no point in frequent releases if versions do not reach the person concerned.

7. Ensure all the person concerned participate in the process
   As practice shows it happens that persons interested in the product are get informed about its development after it have been finished only. At this moment it turns out that their requirement were not taken into account. Be sure you will have to realize even these requirements, but on the late stage of the project, what can cause considerable difficulties.

   Convince all the conferee that their wishes are important and will be considered. Only after some time I realized that several conferee did not understand how significnt can their suggestions be for the others. As a result, many wishes were not expressed because people thought their wishes will not be considered.

8. Priorities should be managed by the only person and this process should be as formalized as possible!
   From my experience of communication with persons concerned, I can say that each of them, probably, will have his/her own vision on the requirements priority and importance. They often cannot come to an agreement about that. Do not take the responsibility for the decision whose opinion is more important — it is none of your concern. Let the head decide what in his/her business has higher priority.
9. Plan changes within the iteration
   Describe in the above-mentioned instruction what should be performed in following cases:
   1. Development team man-hours scheduled for the current iteration are reduced
   2. Customer changes requirement priorities
   3. Customer changes requirements scheduled for the iteration

   As the customer is internal you should be ready to accept his/her wishes in each case. Provide for that how you will redistribute tasks and relax about it. I do not recommend only to shift the iteration date of term — otherwise they will drift and all the planning will come to an end at some moment.

10. Try to communicate more often with the customer
    Even if you plan to end the iteration in two weeks, deliver an intermediate version in a week. Warn the customer that it may contain bugs and should not be used for actual task solving. Do not urge the customer to try this version. If the customer is interested in the product and able ot find some time for it, he/she could be able to advice you something or find any bug before you do. Thereby you can unobtrusively get the customer involved in the testing.
11. Keep the document with requirements in the generally accessible location
    Accustom your customer and yourself to that he/she can at any point learn the progress of work and estimations registered.

Directions of advancement:

1. Introduce the less or more formal procedure of evaluating the product by the customer
2. Register customer responces/ comments on the product
3. Define how the time will be registered that is being spent to organize work, clarify details, meetings etc.

Managing and implementing support requests

In connection with above-mentioned characteristics, to control support requests the slightly different from one accepted for managing requirements way fits better. The same is true for documents. The recommendations are as follows:

1. Create a template for registering support requests
   The recommended content of the document:
   1. Description of that how the system works now. Here you should specify what is wrong in current implementation
   2. The essence of the change that should be performed
   3. Anticipated advantages after request implementation. This item should be filled by a customer
   4. Technical proposals regarding the way of request implementation. If several alternatives exist, you should specify them all here
   5. Estimated man-hours
   6. Technical implementation details. This item describes how exactly changes were implemented
   7. Actual man-hours
   Even if problems with the project documentation exist currently, registering the support request in such form allows you in some degree make up this deficiency. If you need to determine what documents should be created first you can confidently get down exactly to registering the above-mentioned items.
2. Track the state of all support requests
   The good option is to create the document like following:

   1	2	3	4
   <SR Name>	Status	To be executed before	Finish date
   	On consideration
   	Resolved
   	On schedule
   	Rejected

   Above-mentioned statuses («On consideration», «Resolved», «On schedule», «Rejected») may be enough to control the partial progress. There might be no need to set up exact time when the request will be under implementation, it is enough to set up just the date when the request should be resolved. It will be certainly useful to track the actual ending date.

3. Define the order of processing support requests and persons involved
   As well as when planning iteration the instruction may be useful that describes the procedure of support request management. This document in its structure will be almost the same as the analogous instruction that describes software production process on the stage of iteration planning. What about the content, difference is that besides the developer and customer roles, the manager role can be distinguished. Whereas in case of requirement it is implied that manager has already consented to the commencement of works and requirements are being confirmed by the customer representative, in case of support requests the decision to accept the request may not be made by any reason.

Directions of advancement:

1. Probably it will be needed to define more exactly the terms of support request implementation.

One more time about benefits of reports

Conclusions

Common administrative documentation

1. Technological instruction "Software production process on the stage of iteration planning"
2. Technological instruction "Procedure of support request management"

   Project administrative documentation:

3. Document "Project scope"
4. Document "Application requirements"

   Other administrative documentation:

5. Document "Support request"
6. Document "Support request list"
7. Reports