We recommend the Agile development methods, which are in line with the recent shift in project management methodology towards flexible and responsive development practices. Unlike the outdated methods of the waterfall model, a correctly implemented Agile development offer visibility, control, and the possibility to quickly adapt to changing requirements in any software project. Furthermore, we would also take specific steps to address one of the perceived flaws of Agile, which is the relative lack of documentation, by providing JavaDoc style code documentation as well as architecture and design documents.
The items discussed, the sequence in which problems are tackled, and the communication method(s) used depend both on the project type and on the development methodology chosen for that project.In a typical project-based endeavor, implemented with the Agile SCRUM methodology, the process is fairly close to the one described next:
a) You send us the initial information about the project in the form that is most suitable to you. This might even mean sending us the complete specifications of the product.
b) We study the information then discuss it with you to make sure we interpreted it correctly. If you cannot provide full functional and technical specifications for the project we can assist you in defining them for a consultancy fee. The end result of this stage will be either the full product backlog or only a few key features of the solution around which the remaining elements will be built gradually.Whenever necessary, we can send our key people to your site or you can come to our headquarters to ensure a seamless communication.
c) Agree with you on the type of contract to use for the project (e.g. target cost, shared gain/pain, progressive) and on the budget for the project, both at a sprint level and for longer periods of time (e.g. calendar year),
d) A steering group made of members from our team and yours put together a blueprint of the project development process, which covers:
Ideally, all this information will be included in the Statement of Work prepared for the project.
e) We start the project and allocate the programmers in such a way as to meet your deadlines, within the limits defined in step d). Corrective measures will be taken throughout the project lifecycle, whenever necessary.
We have been exposed and adjusted quickly to many approaches. It is no problem for us if we only do coding for one customer and business analysis, requirement gathering and project management for another.
No problem with that. We can use any application, as long as it does the job.
Among the key risk factors we see in any software project we outline a few that might significantly affect the final outcome:
While completely excluding all risk factors might be neither successful nor practical, controlling and reducing these to manageable proportions has to be the goal of a successfully executed project. By applying the right formal project management methodology and adapting it to the project scope and complexity we are targeting successful project completion with measurable progress indicators as well as clear and transparent management processes that are regularly communicated to and reviewed with the customer.
To get things going we recommend having a project start-up (or kickoff) discussion that would address a number of topics ranging from strategic and business issues to project organization, size and scope, planning, pre-implementation and implementation related questions.
The main goals of this discussion are to identify the best ways to interact with our customer and to present our methodology in detail to them. Addressing these issues early in the process can spare us time and effort later on and increase the chances of a highly successful cooperation with the customer.