Let’s take a look at what makes up successful custom software development and the development and project methodology behind it. Here at Ballard Chalmers, we have been honing this since 1997.
The successful delivery of a custom software development project relies greatly on the technical skill of software engineers, but ultimately on much more. To deliver a project on time and in-budget requires a stringent management and tracking system as well as clear communication between the development team and the client.
Project Methodology
To start, let’s look at the management and delivery style that we use. Clear agreements early on mean that both us and the client know what to expect and are on the same page administratively.
We work with our clients to design, develop, support and manage fully bespoke business software systems as a collaborative partnership. What we are doing, fundamentally, is taking the clients ideas, and turning them into software. We rely greatly on the client for the subject matter expertise and communication of what is required. We provide the technical expertise. Hence, this is entirely a partnership engagement.
Ballard Chalmers works on what can be best described as a ‘capped time and materials’ (T&M) basis with development delivery utilizing agile methodologies. We provide this in our unique semi-agile methodology which I will describe briefly in this blog, and we provide this in several ways – Consultancy, Projects, Team Augmentation and Support. This blog is focussed primarily on our Project delivery process.
Delivery Tracking
With capped T&M, delivery is managed and reported on to provide full visibility of progress against budget, so all key parties can at any time see that development is on track. Where there is a divergence in any element of the time/cost/scope this is easily spotted and discussed at an early stage.
When this divergence is short term, commonly, it will be offset by the fluctuations in actual delivery against estimates. However, our tracking will highlight if anything deviates outside of an agreed tolerance and then joint discussions on the best approach can be undertaken.
For example, if the key factor is timely delivery then additional resources or reduced scope would be considered. Each project will have its key factors and it is for that reason we always keep in good communication with the client rather than following automated solutions.
Meetings
The frequency and content of meetings are agreed on in the project kick-off. Normally this consists of weekly calls between our Manager and the corresponding resource at the client and periodic demos following the end of each sprint (often every 3 weeks).
For very large projects it is often appropriate to have a monthly or six-weekly meeting with all key stakeholders where it is felt that information is better shared directly with all the key stakeholders.
Reports
The frequency and content of status reports are agreed on in the project kick-off but can be adjusted as required by the recipients. Our default approach is to issue a written status report on a weekly or fortnightly basis that will cover status, budget, progress, RAID and planning. Where sprints are operated over a longer interval (e.g. three weeks) the reports are normally aligned to be created post sprint closure. Project progress is also monitored in detail using Microsoft Project.
Day to day issue management will be controlled by the Delivery Manager or assigned Project Manager. Should any resolution not be acceptable, or the Delivery Manager feels senior stakeholder input is required this would then be escalated to me (MD) or Geoff Ballard (CTO) for review and assistance in resolution.
Change Requests
Depending on the size of the project we deliver several releases of the system to the client, in agile ‘sprint’ fashion, and review and take feedback as we progress. Out of that may arise Change Requests. These are estimated for time and cost and can be either approved and added to the project or rejected and omitted from the project.
These can include specific functionality requests to be added by the client, or functionality the developers have seen is required but were not included in the scope. It can also be found that some original assumptions were incorrect and additional time (and cost) would be required to meet the objectives or alternately the scope would need to be reduced to stay within the budget.
This variability means the client can control the project for their key requirements, be that budget or scope. No one gets tied into a budget which is not viable or with a scope that is unworkable.
We only accept Change Requests in a written document format and written approval is required for sign-off by the client before committing to the budget and time. This ensures everyone is on the same page and no confusions on misunderstandings mar the client developer relationship.
Development Methodology
Our discovery and project management approach to a software development project is to use a hybrid Waterfall/Agile methodology that we call Flexible development.
We do not believe that a pure Agile delivery is workable as our projects are almost always required to work to a target budget and largely against an existing specification. An Agile approach requires a Project Owner from the client to act as a stakeholder, continually devising and approving stories (a “story” is a small specification for a piece of work used by the developer). This Project Owner needs to decide what is included and excluded from the project on a feature by feature basis, reviewing developed features and effectively deciding on what the final deliverable contains for the given budget and team.
Pure Waterfall delivery is also not appropriate because our first-stage specification does not contain sufficient detail for it to be used as the basis for the developers. And the effort to produce a full detailed specification is time-consuming and needs to be done in advance of detailed cost estimates. Neither of these is a viable option, and that is why we use a hybrid approach.
Hybrid Approach
Our hybrid flexible approach involves:
- Making a high-level estimate based on the existing specifications and clarifications.
- Breaking the system down into EPICs (large stories describing a whole feature of the system) Features and User Stories.
- In conjunction with the client detailing each EPIC. Each EPIC is agreed with the users and cross-checked against original estimates before that section goes into development. Each EPIC is a focussed document concentrating on one area of the system and contains all the information required for both the user and a developer to understand that part of the system.
- Development on one EPIC commences while the next EPIC is being detailed.
Testing
Our test engineers supervise overall testing of the system. Automated unit test is done by the development team and end to end tests are carried out manually. The test engineer and developers devise a series of test scenarios/scripts written in standard Gherkin format. These are then tested manually, and the results recorded.
At each main release, we produce, details of the tests carried out, a report on test passes and failures and known issues along with any workarounds.
Support
Once the project goes into live operation a support plan is provided to ensure that any issues/questions that may arise can be covered quickly and effectively. The post-live support phase is an integral part of the project. An element of bug finding and fixing post-live is expected as a normal element in large scale projects.
In Closing
It is these processes and policies which make up our development and project methodology which allow us to deliver projects to clients in a timely and in-budget fashion. Nothing speaks louder than our 90% repeat client business.
With technical expertise and our fifteen-years of operation (in Ballard Chalmers alone), these policies and methodologies are fine-tuned to create smooth project delivery and successful custom software.
Find out more about our flexible development approach.
Take a look at some of our case studies.
Get in touch and find out how we can help you.
