Agile Methodology
20 years of solution development have convinced us of that the most effective method of developing software is to use prototyping techniques (now also know as extreme or agile programming). These result in effective workable software systems that are developed more quickly and cheaply with better quality and closer to user expectations.
We have often used prototyping ( or Agile Methodology) techniques in organisations where "formal techniques" have been the norm. The catalyst for this is often an urgent or critical requirement and our clients have been amazed at how quick and easy it has been to develop these systems.
There are a number of ingredients that are essential: •Committed management •A committed project sponsor •Knowledgeable user evangelist •Experience results orientated programmer analyst •Modern powerful application development tools and software (Visual Basic, C# , Access, SQL Server, Visual Studio).
Each of these ingredients is essential for a successful software project whether carried out with RAD or any other techniques.
Rapid Application Development is a group of techniques that covers many areas. It is more an art than a science and is based on the experience and goodwill of the participants involved. But the results are dramatic.
Case Study 1
A corporation found that it was loosing some of its largest customers to two of its competitors who were providing software that described their products and simplified ordering.
Our client which has a much broader range of products and services asked us to create software that would enable the promotion and ordering of their products by major customers. It was critical that this be done quickly and provide substantial benefits to the customers.
After the brainstorming session with senior marketing executives BMS built a prototype system. This was completed and refined over a period of 3 months into a working system for distribution to customers.
Not only did the software prevent customers from moving to competitors but a substantial amount of new business was generated. One of the competitors withdrew their software from the market and the other took 2 years to upgrade their software to rival the functionality.
Case Study 2
A photographic business asked BMS to build an E-Commerce site to cater for their customers from all over the world. The web site was very ambitious in that it sought to provide sophisticated customer ordering and product definition. They had been told it would take years to achieve.
After a 3 hour meeting with the chief executive BMS was able to build a Web application with the desired properties in a matter of weeks. It turned out that the requirements were not as complex as first imagined and could be achieved with existing technology.
Case Study 3
A company in a highly visible consumer market identified a national mainframe order tracking system in October 1999 that had been overlooked and was not Year 2000 compliant.
BMS was asked to urgently build a replacement system that would be year 2000 compliant and could carry out the major functions required. Meetings were held with senior company executives and the most experienced system user.
The resulting prototype system was so effective that little change was required for the production system. The software was built in 4 weeks and commissioned in early December 1999. Not only was the original system replaced in such a short period of time but substantial additional functionality was provided.
Case Study 4
BMS had been providing software development services for a number of years to a large corporation that is a household name. The IT manger asked BMS to take over the function of their internal desktop systems development group. This was because they found that the internal group was not able to provide development services with the speed and cost effectiveness that BMS could. The difference was not the competence of the staff but the our experience, methodology and development tools that we use.
Our Methodology
At BMS we develop efficient bullet proof computer applications fast and at a surprisingly low cost. We can do this because we use the best people, the most modern computer tools and Rapid Application Development techniques.
Our methodology involves a "Leading Consultant" from our staff who carries the overall responsibility for the project and a "Leading Representative" from client organisation who carries the vision of the proposed project.
The "Leading Consultant" and "Leading Representative" build the system between them using the specification as the underlying guide (often we build systems with no specification at all). This approach optimises the lines of communication, the minimizes the opportunity for misunderstanding and optimises the development time for a project.
Other staff are invited in as and when required to resolve particular issues or to approve project milestones. Often a "Leading IT Representative" is involved also to verify the use of standards and technology related to the clients IT policy.
It is crucial that the Leading Consultant be highly skilled and experienced in the following areas:
•verbal and written communications •systems analysis and problem determination •software architecture and design •programming in the chosen programming environment •project management •clarifying user requirements
BMS staff who act as Leading Consultants are highly skilled and experienced and have acted in this role on numerous occasions.
The "Leading Representative" should have a good grasp of what is required by the users of the system to be developed. It is vital that the Leading Representative has the authority to call upon other staff and vary the specification as necessary. The Leading Representative also plays an important role in the design of the user interface, acceptance testing of the software and training and implementation.
This person should be skilled and experienced in:
•Work practices of the system users •Contents of the system specification •the business practices and functions of the work area being addressed •technical issues related to the system to be developed
While this is our preferred methodology we also work with many other methodologies that are used by our clients. This includes traditional specification and project management approaches.
Other Observations
Written specifications can never adequately express what is required. The more they try to do this the more unproductive time is required by the specification writer and the specification interpreter. While some written specifications are always necessary these should be kept as brief and succinct as possible.
A half hour meeting between a system evangelist and system builder is many times more effective and accurate than copious written specifications.
Tendering results in a large loss of efficiency. The process of preparing specifications, responding evaluating responses is often more effort than the development of the system. Add to that the fact that there are perhaps 5 responses and only one of these is successful. However time must be spent evaluating and examining each of these. Looked at over a long period of time this is a very inefficient process. In addition tenderers need to build in a substantial margin to cover the 4 out of 5 tenders (on average) when they will receive no return.
For these reasons BMS does not respond to tenders. This enables us to provide much better value to the clients that do use our services.
Large consulting organisations cannot provide that same level of productivity and value as smaller companies (such as BMS.) This is because the larger organisation have thier most experienced staff involved in management and administration of staff rather than working on the task at hand.
When you deal with us you know that the person doing the work will be an IT professional with over 20 year of experience and a track record of success - rather than a junior at end of a long chain of administration. Add to this the high staff turnover of most large computer consultancies and the advantage of dealing with an owner run business is clear.
The reduced management and administrative overhead means that our rates are very competitive.
