Process improvements can come in a multitude of flavors and personalities! Sometimes they're born out of pain from losing clients to a competitor or merely frustration with an internal process that takes a lot longer than it should. Below are several of the PI projects to which I've had the opportunity to make contributions.

Situation Management

• We designed and implemented business process improvements for a 24x7x365 team chartered with managing very technical teams, ensuring they resolved high-severity, revenue & customer-impacting production systems’ outages. This team's performance was very visible to management and governed by a very strict SLA (Service Level Agreement).
   
• One of the challenges of working with this team was overcoming their desire to "jump to solution" rather than first determining the cause of the failure. This may sound rudimentary but, given that the team was newly formed from the application and network groups where problems usually occurred, they had a natural inclination to immediately think they knew how to fix the issues (the "SME" effect). Instead, management wanted them to learn how to manage the teams that were fixing the issues, not actually fix the issues themselves.

• The SLA's dictated that, if they weren't at a particular stage in the problem solving effort after a prescribed time, the issue must be escalated to a higher level. So, for example, if they moved directly to fixing the issue and later found their original idea of why the problem existed was incorrect, they had probably already eaten up an hour of a 4-hour SLA and had to start all over again.

• Our solution to this dilemma, developed collaboratively over a period of weeks, was a very structured issue resolution process with definitive gates that needed to be satisfied before moving to the next phase. Once implemented, this solution improved relationships between the team and those they depended on to resolve the issues and vastly improved their ability to meet their metrics. 
   
• To help manage the team's change to the new procedures, we web-enabled tools & training material to improve real-time communication of issue status to individuals and management outside of the team, and implemented improvements to their Remedy tracking tools. This improved the data collection process from the team, freeing them to focus more on their issue management responsibilities.
   
• At the request of a Command Center chartered with managing similar high-severity issues in a test environment, we transitioned the team’s knowledge of best practices and repeatable processes to them, bringing the Center up to speed with the newly standardized processes.

Greenfield

• We "started from scratch" on this one. Most IT organizations have a process - an SDLC or Systems Development Life Cycle. We had a clean slate on this project as there were no documented procedures for the developers to follow, just coding. By today's standards, there were no Business Analysts to liaison with the business side. That was it. Not so much as a Process Improvement project but a Process Development project. A true Greenfield.
   
• We started by identifying and meeting with the major stakeholders...management, including the IT manager, users or their representatives, whoever represented the (external) client, and anyone else who had an interest in ensuring that the IT organization delivered value.
   
• Through a series of brainstorming and JAD sessions, the outline of an organized workflow became evident. We started at the end of the stream and worked backward, each step defining the inputs and processes necessary to generate the desired outputs. For example, one output was payments to be exported to a particular client. We mapped all the data required by the client, along with the format specifications for that file. We then considered the processes and calculations necessary to generate each field in the file and the potential source(s) for that data. That became a basic specification for one or more applications to be built along with basic database designs. All along we were working with HR and IT management to lay the groundwork for any new skill sets required as a result of our findings.
   
• Eventually, we worked our way to the beginning of the workflow and identified inputs necessary from sources both inside or outside the organization. This led, then, to bringing representatives of the external organizations in to collaborate with us on our interfaces. Internally, we began designing data capture ideas that would eventually be used to create applications for data-entry resources.
   
• As our framework began to take shape, we initiated a sub-project to develop repeatable processes for future system development - an SDLC. We had many sources to draw upon, such as IEEE and the Rational Unified Process, and used these to develop the templates and training necessary to truly engineer a culture change at the company. This included aspects of communication planning, discipline, standard operating procedures, a Project Management Office and a Quality Assurance team successfully integrated into the end-to-end process.