0102 Process Methodology

NOTE:  THIS SECTION IS ALSO PRESENTED AS A “KNOW MORE”  IN THE PROCESS MAPPING SECTION OF PROCESSSTEP GOLD.  IT IS PLACED HERE, AS PART OF THE “LEAD-IN”, TO FAST TRACK THE USER INTO THE METHODOLOGY AND TO FACILITATE A QUICK GRASP OF THE REST OF THE PROCESSSTEP INFORMATION.

About this Section

This section provides details on the ProcessStep Methodology, showing  

  • Why ProcessStep works

  • The Starting Point

  • What Business aspects are impacted

  • The Roll-out and how ProcessStep is applied to create the agreed Output

  • What is needed to Present ProcessStep

  • Your Task during the Presentation.

  • Tips

  • Tool Kit

This information is used to explain, at any time during ProcessStep Roll-out, what ProcessStep is and how it works.

Why ProcessStep Works

  • ProcessStep results in detailed Process information being extracted from, and developed interactively with Role Players who Participate in structured Workshops. 

  • Information extracted during the Work-sessions is recorded and presented in a user-friendly, visual format illustrating Process details and concepts that are easy to interpret.

  • The methodology works because: 

    • Ownership stays with Role Players and is enforced in each Work-session.

    • Change Management and Improved Practices are part and parcel of each Work-session.

    • Interactive Participation clarifies roles and responsibilities.

    • Process Maps are fun and intuitive to follow.  A short learning curve is needed to read and understand ProcessStep Maps.

    • ProcessStep works equally well for Business and for IT “people” and “connects” the two disciplines.

    • It focuses on Outcomes.

The Starting Point

  • ProcessStep starts with a Process Owner and/or Client Project Owner or Manager who have a “Vision”. 

  • The Vision may include Change, Improvement, Re-Design or New Direction. 

  • Usually there is the “Now” status, representing current Processes and Outcomes and the “There” status, represent a future, changed environment, Processes and Outcomes as shown in the diagram below. 

  • ProcessStep creates the path to move from the “Now” to the “There”. 

  • Before ProcessStep starts, it takes note of current, or existing documentation, previous work and makes a call on how to proceed.   In other words “can the existing work be used as input or is it a fresh start”?

  • Once the Vision is clear, ProcessStep Goals and Deliverables are set in the Project Plan. 

  • The Project Plan drives the high energy ProcessStep Activities as shown below. ProcessStep is H-I-G-H  E-N-E-R-G-Y because of:

    • The drive of the ProcessStep Team and Participants to deliver planned and agreed Outcomes.

    • The interactive, fun way in which Work-sessions are conducted.

    • The new ideas and improvements that are developed and agreed to by all Participants in the Work-sessions.  This means that there is a high level of interactivity, consultation and opinion-sharing that occurs throughout ProcessStep.

    • The way data is captured, using Icons along with words.

    • ProcessStep’s “exploration” of each of the following elements:

      • “Business Stuff” where Processes and Procedures are developed and/or unpacked and documented.  “Unpacking” a Process means that it’s Purpose, Scope, Activities, Role Players and other ProcessStep Elements are identified, defined and recorded.

      • “People Stuff”: Processes are driven by People in most cases.  This means that ProcessStep recognizes what motivates Role Players, where “people issues” cause breakdowns and what interventions are needed.  Action Listing addresses these “people gaps” and may result in Team Building, Personal Coaching, Diversity Programs, etc.  All of these infuse People and Process with energy.

      • “IT Stuff” where the Process requirements are evaluated and matched to current IT Systems and gaps identified.  These gaps are addressed and IT Role Players become part of the “Improvement” or “Best Practice” effort. In Systems Development Projects, ProcessStep drives out and validates business requirements.

      • “Compliance Stuff” which defines the boundaries within which Processes function. It also aligns the activities performed and how they interact with Statutory and other Directives, (for example Sarbanes-Oxley, Laws, Policies, Charters, etc.).  This aspect results in Role Players - often for the first time - becoming aware of how Governance is translated into Step by Step activities. 

    • The way time and Output “chase” one another to deliver on time what is planned.

    • The “fast track” drive to implement Action List items as Element of Change Management.

  • After the “New” or “Improved Practice” Processes have been Work shopped, Mapped and if relevant, documented in Books, the Management Application further “unpacked” and/or the WorkBook has been developed, “Testing” takes place.    Testing may require further Process refinement and Actioning.

  • This is followed by continued Implementation and Change Management, where some Actions may become embedded in Portfolios and implemented as Projects or as part of Projects. 

  • Evaluation is continuously used in ProcessStep, both during and after the “high energy” phase. 

Evaluation as shown in the diagram below ensures that the ProcessStep Team and the Client continuously verify that Project Goals are being addressed and appropriate Actions are implemented to achieve results.

Ongoing Evaluation measures whether the Vision is being met.

Since Vision and Goals are dynamic, the ProcessStep route repeats itself as often as is needed and in sync with Entity growth.  In each reiteration, new and improved Processes are developed.  Seen from a different angle, ideally ProcessStep should become part of how Entities run their business. 

This means that ProcessStep (as an iterative tool)  in year one for instance, documents and improves Processes, in year 2 ProcessStep focuses on further improvements in Processes and on new Processes that came about due to growth, changing environments, etc.  

For each iteration, ProcessStep can be deployed as a Project should the Business or Entity Management so choose, with a start and end date for each successive iteration. This means that the outcome of each Process Evaluation kick-starts a new ProcessStep Project.

[ Previous Page - 0101 ProcessStep Structure]  [ Next Page - 0102 ProcessStep Impact]