Here at Web Design Magic we have literally spent years and years attempting to perfect the best methodology to invent software or create websites and systems. In the beginning, very much like any up and coming software house, we seemed to jump in and start building without to much thought into any processes either functional, legal or visual.
In the past 10 years as the industry evolved so did methodologies. Methodologies are rules (not set in concrete) that we have been told to follow in the attempt to create the perfect website on budget and on time. Anyone in this game knows how hard this is to achieve. Some methodologies suit some people and/or programming languages and others just don't suit at all.
We use multiple methodologies here; however our core is the MSF (Microsoft Solutions Framework). Even “out of the box” this framework is far too complicated for the average web design company as it is designed to be utilised by software developers, systems administrators or engineers. However, the basis of this methodology is strong and well supported in the community.
We have taken core elements from the MSF and applied it along with other concepts to create a methodology to develop websites that works for both ourselves and our customers.
|
|
The MSF is broken into five main parts or phases. Envisioning, Planning, Developing, Stabilising and Deployment. All these phases are required in any lengthy project or customisation. However, we typically do not worry about this amount of detail with small packages or standard CMS products.
It is how we utilise and manage these stages that make our methodology ours and outlined below is the basis to how we work.
|
Making Real Software
In the past we typically wrote strong and strict functional specification documents that we had to adhere to and this was how we gauged our success. Unfortunately, this made it unrealistic and time and time again we saw software being rushed to meet the document scope and deadlines. Although, we still feel it is VERY important to have a functional specification document, we also believe that we should loosen up on the nitty gritty in these documents and start writing real software.
Long gone are the days of writing software from scratch. People do not have the time or budget to do so; instead we find ourselves “customising” pre written software, like our CMS, Online Store and SharePoint products. The creators of these software solutions have made their products with this in mind and as developers we can really customise any part of these products to suit customer requirements for a lot less cost and in a much faster go to market time than the old school way.
Customers love to see things on screen. There is nothing worse that attempting to show a customer a concept on paper (written words) or try to explain to them your ideas. The best way is to show them what we feel this tool can do for their business problem and give them something to look and play with fast. They can then typically find ways around the product and see what customisations they really require, what can be completed in later stages and what can be completed with their current budget.
Below is a flow of how we typically handle a medium sized project.
Firstly, both our sales and development team discuss requirements with the customer and based on what we know about our products and the constraints we provide a “ball park” budget for the project. It is at this point the customer will have an idea on what “built in” features will be suitable and what customisations are required. We then proceed with formal agreements and install a “Vanilla” copy of the product. This has NO customisations and is set up to what we believe is as close to the customers initial requirements.
It is then the customers turn to “play” with the software. Customers love this part. It has only been a matter of weeks and they are using their new software. This is the real part. Real software, no confusing documents - just juicy features! The customers then typically have a bunch of questions and provide these in a report.
Our development team, who by now have a great understanding of the requirements, then provide a more concrete time estimate for customisations and they are documented and called a “Functional Specification”. It is this document that is our blueprint for the project and it is our mission to get the price as close as possible to the ballpark first issued - Assuming the customer has not changed his mind. When the customer decides on what customisations need to be present in the first version the developers get to work. Once completed the customer completes their UAT (User Acceptance Testing) and provides a report. Any changes are made and the site goes live.
As you can see it is not really that hard. The whole methodology is designed to be fair on both parties as well as stop re-invention. Nine times out of ten customers find a way around a problem with existing functionality and this is perfect as it reduces the total cost of the solution.
37 Signals – They are onto it!
A great read is a book from 37 Signals. Pavel, one of our developers here on the Gold Coast put me onto this book and it has changed the way we develop software. Microsoft is even adopting these methodologies in their products to increase the time to market and reduce software development budgets.
You can read more about 37 Signals here - http://gettingreal.37signals.com/
Or the inspiring book at - http://gettingreal.37signals.com/toc.php