Keys to Success: People, Process, Technology

This blog is focused upon best practice for software development - typically using SAS software. It can sometimes seem like an eclectic mix of stuff, but there are an awful lot of things that contribute to making great software. But think about it, it's not just about making great software. Most of us have discovered that building a great new software tool will not always produce a successful project outcome. The saying "a fool with a tool is still a fool" springs to mind. The tool is only as good as the Processes that wrap around it. Taking it a stage further, the Processes are only as good as the People that use them.

People, Process, Technology - PPT

The most important factor is People; get this right and the rest will follow. You need to be sure that the users of your new, shiny SAS system are properly trained in all aspects of the system and have the appropriate professional skills, experience and qualifications too. For example, making the most effective use of SAS's data mining technology requires data mining skills, not just a knowledge of what the buttons and menus offer.

Beyond people, Process is crucial. You need to build and document your business processes and workflows before you get into detailed design of your technology, else you'll end-up with the tail wagging the dog! Train your people on your new processes, but be sure to involve them in the development of those processes in order to get their buy-in.

But, what is a business process? Put simply, it's a sequence of activities, started by a trigger event, and ending in a defined output and/or output, with specified steps performed by specified people/roles. Some examples would include:

Process#1: Produce new churn report
Trigger: Request from head of marketing
Output: New, scheduled churn report delivered to information delivery portal

Process#2: Credit score a potential new loan customer
Trigger: Potential customer telephones call centre
Output: Accept/reject potential customer's request for a loan

You need to define processes for a variety of aspects of your system, not just the business outputs. Make sure you have processes that cover support and administration too. Earlier this year I did a post-implementation review of a multi-million pound SAS analytics platform whose development had focused on technology and pushed people and processes to the side. The first few weeks after go-live had been very painful for users, IT and sponsors alike. Seeing the problems, everybody had pitched-in and had stabilised the system such that it could be used productively, but the post-implementation review warned that the system would not remain stable if  proper processes were not put in place quickly.

Some of the things highlighted in the post-implementation review were:

• No data governance model, including an absence of data ownership/stewardship/custodianship, and an absence of a strategy for dealing with data quality and data loading issues
• No change control processes for handling new groups of users, requests for new data sources, etc
• No defined support processes specifying single points of contact for key areas

At its simplest, you can document a process as a series of steps, with one or more trigger events, with inputs and outputs for each step, with named people or job roles for each step. Swim lane diagrams are often used to document this information. Start by capturing the big steps in the process, then drill into the detail.

Ignore processes and people at your peril: the success of your project depends on them far more than the technology!