Bitworks Stone Garden

Our approach to complete projects successfully

After several years of software development we found our approach of how to develop software fast with guaranteed quality in the budget. In this post I will describe our approach because I see the necessity of such material for our customers and other software development companies around.

First of all let’s see at the project in the head of the customer. He sees business ideas, targets, general overview of the product and how it will solve business tasks. He is not aware about the details, features, new facts, new conditions, etc. As a result when any of above reasons occures in the process of development which leads to change project budget the customer becomes angry and unsatisfied. Our way is to avoid customer unsatisfaction and work in the way he is always satisfied. Even this approach sometimes leads to the moments when customer is not satisfied but you always must have bullet-proof arguments for him to show this is not a failure but just the thing we aknowledged about.

Ok, the customer satisfaction way starts from the project aknowledgement. At this stage the customer meet our CIO (God bless him!) and explains the project with details and gives him the documents regarding the project. Sometimes he can even give some kind of specification to our CIO and this really helps us. When our CIO knows enough about the project and ready to work on the specification he said to the customer about rough estimated timeline and project cost. If the customer really ready to spend such a budget for the project we begin to work on technical specification. The most important document in the software development. The technical specification must include all necessary facts about the project including user interfaces, software characteristics, conditions and responsibility of the customer and developer. Yes, this is really faithful if both parties has responsibilities and this is very important because the customer is also the part of project team and he must participate at the software development. He is responsible for several very important things:

• be online and solve ongoing questions as fast as possible; your conditions must include the point about customer blocking delay which leads to project delay and additional expenses; your customer must agree with such a condition;
• if the customer changes the specification or adds some additional features into it then this leads to budget review and it could be changed;
• if the customer realizes that the project is not he want (for example, business conditions changed) he must to pay not only for spent time but also for time of the nearest future; why? – because it’s difficult to find new project in a couple of days and if the developers will not be busy then the developer will fail;
• the person who will answer the questions of developer must be obliged to do it; we found the situations when the person who “wanted something” wasn’t obliged to request it and it causes conflicts;

Other conditions are standard and I will skip them here. If you know another important things I missed please let me know!

After technical specification completed and agreed with customer and development team we build our internal document – memorandum about the project where we list all important facts about the project on two pages. Here these facts:

1. Specification developer
2. Project manager
3. Project team (developers, testers, etc.)
4. Customer
5. Project schedule
6. Project funding
7. The agreement where all participants agree that they are acknowledged about the project and ready to complete it in the specification conditions;
8. CEO, CIO, CSO signatures.

This easy and small document allows us to see what we are going to do with that persons and helps us to feel responsibility for the project better. It’s like an holy cow.

Our specification is build in such a way we know all the use cases and interfaces of the project and can easily to convert them into the tasks for software developers. Our approach avoids deep architecture planning where possible and we are using our inhouse software to manage the project schedule. What is the software? We call it processflow and it was developed to track the tasks and time spent. It uses managers, developers and administrators to organize projects into the tasks and allows developers to run them. This approach allows us to see how much time we spend for the proejct and control the schedule.

When our project first time delivered to our customer we provide him with access to bugtracker and he is involved as the person who makes a feedback. The bugtracker software is also used by our testers to do internal software quality assurance before release to customer. We are using trac bugtracker now as it’s has integration with SVN, very simple and developers like it more than mantis (which was used before).

Thus after the first release and for all the time our customer participates in the development process as the expert and beta tester.

To be in touch our project manager who is responsible for the project meets our customer several times per week (usually 3-4 times) to discuss the project status and schedule with him and to inform him about ongoing tasks, required actions from the customer party and so on. This is the very important point in our development process. Remember, the customer always need to know what happens and you must deliver such a knowledge to him.

And this is not the end. Our project manager writes reports to the customer in order to provide development status in short and with major details. This helps to get the customer all development in touch and this helps us to know when some fact was delivered to customer.

Project manager is also responsible for adding the tasks for development team in our processflow software which allows to control the budget of the project. All the tasks including bugtracking, functionality and so on are in the processflow. We know how many hours we spent and want to spend on certain project. This is necessary.

When the project has moved to support stage the way of collaboration with the customer changes. Often we offer fulltime support for big projects and hourly-basis time support for small projects. This allows us to utilize development resources and provide good service for moderate finance. The disadvantage of hourly-based support is that in this case the developer often participates in another project and just spends several hours to support old one. This may cause the delay and we acknowledge our customers about it.

That’s almost all about it. Best regards, Ivan Kudryavtsev