As Director of Services for Hannon Hill, I am always looking for ways to improve our processes internally to ensure a high quality of service.  Sometimes, that involves a little Rapid Application Development (RAD). 

Recently, the Services team took on the task of analyzing the entire process of a project moving from the first product demonstrations on the sales side to their transition and ultimate project execution on the Services team.  We wanted to identify ways to make the handover from sales to services run more smoothly, and we also wanted to manage projects more efficiently.

After a few requirements meetings, we realized:

• Project scheduling needed a more scientific approach that would allow us to know what was coming down the pipeline from the sales team long before any invoices go out. 
• We needed to be able to see an actively updated list of clients and prospects so that we could be more proactive with scheduling clients. 
• We wanted to be able to see a daily status update of the currently active projects which would permit us to move resources around more efficiently to projects that needed our immediate attention.

It all sounded like a great challenge!  It was clear we were going to need to develop a system that would help people accurately communicate critical information. We got to toss around a few business 2.0 buzzwords and phrases like “establishing a new ‘paradigm’ to generate beneficial ‘synergy’ throughout the office.”  I am sure that some would say that we went for the hat trick by touting that it would have some “web 2.0” features to make interaction with the system more intuitive.

Since there was no existing code for us to reuse, we had the freedom of starting with a blank slate.  We identified several technologies and frameworks that would give us the most flexibility while lowering the total time spent with maintenance of bugs and feature improvements in the future.  Although we have skilled Java and PHP developers on the Services team who could have whipped up something really nice, the complexity of maintaining such an application would be best handled by the same developers who coded it.  I wanted to make sure that whatever framework we used would be easy for anyone (including me) to go in and modify.

After mulling over the benefits and drawbacks with taking a pure coding approach to our new web 2.0/paradigm-driven/synergy-generating system, we realized the best option was right under our noses.  Using Cascade Server we could create a framework for a fully functional prototype of our system within a couple of weeks (once we had a full understanding of our business requirements, of course).  By using XML-based data definitions and XSLT, we could provide the application with a means for data collection that would require minutes of developer time rather than hours to create.  The whole mix equaled quick time to production with a RAD cycle.  It will also ensure easy future modifications as our needs grow and change.

We completed the project in just enough time for us to take on quite a bit of project load. Now, with our new application making so much timely information available, we can focus our efforts towards measured planning and smart allocation of resources, and away from ad-hoc management. 

In short, we saw a business need and were able to realize tangible benefits from its implementation in weeks rather than months – one of the virtues of rapid application development.  One of the advantages we’ve seen using Cascade Server in-house is that it’s a tool that we can continue to extend to meet our internal application needs.  Moving beyond just using our CMS for our internet and intranet sites, we’re able to quickly develop solutions to problems that will keep everyone on the same page.

I’ll be speaking more on the topic of Rapid Application Development and Cascade Server at our upcoming Cascade Server User’s Conference.  Hope to see you all there!