The first Cim Social Business Process app I wrote about was Product Ideas. That article was also a primer for the new line of process apps based upon Cim. It is a bridge between classic idea and innovation management scenarios and our more standard business process apps. Let’s take a half-step forward and look at a different social business process – Application Change Requests.
Application Change Requests Overview
This is a common process for an IT Department to manage their changes to software applications. It is also a core process in a Product Management department for companies such as CorasWorks that publish software or use software in their solutions and systems. Many organizations lack a formalized process supported by a system. They may just use emails, meetings and/or excel spreadsheets. Often, how prioritization decisions are made is at best a secret and at worst unknown. In addition, most lack a social element that can be used to rate/prioritize (either end-users or people involved in decision making) and/or enhance CRs with comments and information. Further, they often lack the feedback loops to keep contributors and their “customers” informed.
Keeping to our standard of consistency of our Process apps, below is the process map for Application Change Requests (green dots are social, blue are process management). Note that it is very similar to the one used with Product Ideas. The names and purpose at each step are a bit different, including, the stage-gates of the CR process.
The Process in Practice – CorasWorks Product Management CRs
This is a process I know well. We use this app internally. It is used by our Product Management organization to track all change requests to products. The CRs may be bugs, new features, ideas, designs, documentation, etc. We have a Change Control Board that reviews the CR’s.
Below we show a screenshot of a recent Change Request for Cim. Note a few changes in what information we capture and display that are different from the Product Ideas screenshots.
- We show a CR number so that it can be referenced to external customers and internally.
- We log the customer that came up with the CR.
- We show the Status and a visual view of the workflow and where it stands.
- When it gets into a product release we reference that.
- We also show the request type.
When CR’s come in they are screened in the first week. Then our Change Control Board reviews them. They may move them forward right away, try and get more information, prioritize them, and/or look at the level of effort and impact. When approved for development they are assigned into a product release and tracked in our project system.
Why it Works for Us
Here are the core reasons why this Social Business Process works for us.
- It is easy for people to contribute. This is really important or else email chaos and politics rule.
- The feedback information is at the fingertips of our customer facing people.
- Our process of prioritization is highly visible.
- Because of the first three, our employees participate at a higher level.
- At the end of the day, we know what we did and did not do (real key) and why we did it.
- The front end process ties into our back end development system which is also in SharePoint.
- It serves our core purposes without overburdening the process with details.