Within Click Commerce Professional Services, we are always looking to improve ourselves. A team that is content to continually do the same things the same way is one that will cease to be relevant, so recently I’ve begun to take a hard look at how we begin the process of implementing a new customer solution.
At a certain level of abstraction, most projects follow a common pattern. This is true no matter the project or technology, but becomes even more true when all projects leverage the same platform. All Extranet-based solutions have the following elements in common:
- Workflow
- SmartForms
- Notifications
- Business Rules
- Presentation
- Reports
- Robust, context-driven security
- Integration with external systems
We begin each project by demonstrating our starter solution then walking through the workflow in detail with a broad customer team representing as many of the different constituencies as possible, including the central administrative staff, project sponsors, other domain experts, and the development team. This approach has proven incredibly valuable in refining the project requirements by identifying where the specific customer workflow deviates from (or is the same as) the workflow in the starting solution. From this Kickoff meeting, Click Commerce is able to define a detailed project implementation plan. This has been a well established process for the past few years and it has been very effective. I have to ask myself, however, can we do even better? It’s good to challenge the status quo now and again, right?
If you look at any Click-based project objectively, it’s easy to recognize that Workflow is only one part of a complete deployment. Observing the course several projects have taken recently, I’m beginning to think that SmartForms are just as important to understand early in the project. To put it another way, the method of collecting data is just as important as the path that data takes through its lifecycle and understanding both as early in the implementation project as possible increases the quality of the initial design and reduces the need for costly design changes later.
Many years ago, IBM promoted a system design process called JAD which stands for Joint Application Design. The whole premise of this approach was to examine the current paper-based process as a way to design a new computer application. Many aspects of that process now seem “old school” but, as is often said, there are very few truly new ideas. Most are improvements on old ones. The process we use at Click certainly doesn’t break new ground but has been tailored to our products. The JAD process promoted a multi-day working session, where all of the domain experts (people who actually follow the current process as a part of their actual jobs) get together in the same room and talk through their jobs. Each is required to bring with them the paper forms they work with and describe how they are used in their part of the process. I participated in a few of these JAD sessions and it was surprising to me to discover how often one person’s part of the process was completely unknown to others involved in the same overall process. Jobs functions tend to get pretty isolated and silos are a natural result of people being so busy it’s all they can do to focus on what they have to do. There’s no time to understand the nuances of another’s job. The one thing about JAD that I came to appreciate was that it focused both on process and information collection. Understanding what information is collected and how it is collected was the real driver for designing an effective data model.
Fast forward to the present. In our Project Kickoff, we demonstrate the starter SmartForms and Workflow then spend the rest of the kickoff walking through the Workflow in detail in order to identify customer specific deviations. Is workflow the right place to start? I wonder what would happen if we began by understanding the what and how of data collection first then followed that up with a discussion of how the collected information travels through the workflow. I see several benefits with this approach:
- After the demonstration, the Kickoff continues with what is most familiar to the assembled customer team – the current forms and a discussion of what works and what could be better
- A clear understanding of what goes into the project makes the discussion of workflow and the review process easier – we now have better context
- An understanding of the collected information is the first step toward a solid object model
- Workflow cannot exist without the object model. If the model supports the data collection process from the beginning, the implementation of the workflow, SmartForms, reports, and presentation will be easier and will result in less rework caused by having to change the model when implementing the SmartForms and less need to implement creative solutions to leverage the model upon which the workflow is based
Is the information collection process more important to understand in a Kickoff than Workflow? That’s a tough question to answer. Understanding the workflow is critical as well and ideally both should be discussed in detail as early in the project as possible. I wonder if that would be too overwhelming to the Kickoff attendees to cover both topics during the meeting. My crystal ball gets a bit cloudy at this point. However, I’m of the opinion that extending the Kickoff to cover both would result in even better and more predictable implementations.
I’d love to hear your thoughts on this.
Cheers!
