I ask you, how can you know where you are going if you don’t know where you have been?  Do you know who is doing what and what role that is in the organization no matter who sits in the role?  Do you know where your manual processes are and how you might achieve efficiencies with system support?  Do you know what rules are necessary to ensure when you follow the process that you are in compliance?  Are you aware of the boundaries and how the HR process may be impacted by the Recruitment process, or how the supply chain process may be impacted by procurement. 

It is always amazing that there is someone who indicates process is not important, or we don’t need to do that until we get into designing the system and writing the specs.  Process Analysis needs to happen up front to determine where the opportunities are for change, how change will be instantiated and communicated, what training will need to take place, does the system support the process or not?  Are there other systems that are integral to the process?

Here are some questions to ask yourself and ensure you have the answers and your processes analyzed to provide a framework and foundation for everything else in your implementation.  The foundation will be there for testing, training, security, roles, compliance and ultimately change and communication. 

Questions;

What is the purpose of the process, outcome and result?

What are the Roles and how will they change?

What are the steps?

What are the business Objects?

What are the rules?

What is manual and where does the system support the process?

What training and testing will be necessary to ensure the process is working as planned?

What are the boundaries between processes and what is the impact on pre and post process?

How will all the changes be communicated and managed?

So if you think process is not important, look to those implementations where you have been involved and determine points of failure.  And on those that were supported by Business Process or Use Case Analysis how they had an impact on success. 

I remain amazed that there are still consultants and professionals who do not understand the value of understanding and anlyzing process at the beginning of an implementation…not in design, not in construct, not in transition, not in deploy but in the beginning to provide a foundation for all stages, phases and tasks involved in an implementation.

Objective of the Meeting
The purpose of this discussion is to provide a foundation for decisions and definition of your system and
processes during the Discovery Sessions. The discussion will center on some of your current
information and discuss ideas for the forthcoming implementation. Please participate to the best of your
ability.
There will be information and additional research that may be required following the discussion sessions.
What is needed for Process Analysis:
• Ability to conceptualize future state
• Roles: Who does what in the process
• Boundaries: Where does the process start –end.
• Pre-Post Conditions
• Rules: Regulations
What are your pain points?
Are there points in the process that could be eliminated?
Are there manual processes that you would like to have supported by the system?
What changes are you most apprehensive about in changing process?
Keep the following points in mind as we discuss process:
Points of Discussion
Base Benefits
Do you have Benefit Programs?
–What differentiates the Programs?
How many Medical Plans?
How many Dental Plans?
How many Vision Plans?
Plan Summaries, Plan Documents
Benefits
Describe your benefit types: (Examples)

• Long-Term Care

• Medical

• Legal Services

• Wellness Credit

• Vehicle

• Uniform

Base Benefits Dependents/Beneficiaries
• Child
• Employee
• FostChild
• Grandchild
• DPAdult
• Dom Partnr
• DPChild
• Other
• OthQ Dep
• Stepchild Child
• Spouse
• ExSpouse
(Provide any manuals or reference procedures if applicable)
I am sure anyone who has conducted informational/discovery sessions will have information and questions to add to this blog. Please feel free to send additions or comment.

More projects fail because of poor change management than probably any other factor.  People do not like change and it is important to develop a change management and communication plan.  Identify that person in your group who loves to lead the charge on change.  Then develop a group discussion on how this project will impact the organization.  Draw an organizational chart on the board and circle the stakeholders.  Look at how the project will impact end users, customers, managers, executives.  How will that change be communicated to each of those groups.

Identify the leader who will begin to develop the change plan.  How will the team be structured to complete this deliverable.  A draft should be completed by the end of the week and a group will need to work on the content and strategy for that deliverable.  You can facilitate discussion in the large group and then assign a small group to work on the deliverable.  Or you can have several groups assigned to change and communication items for the plan.  Don’t hesitate to assign homework so this is completed and ready for presentation by the end of the week.

What are some of the creative ways to communicate to the organization?  Do you want to develop a web page? a newsletter, tweet program, blog, regular program for sending emails?  Will the communication look different for each group?  Let the group help stimulate this discussion and get a feel for the culture of the organization and how it communicates.  My experience in organizations demonstrates how communication differs, a small organization may communicate only by email, others may have formal presentations and still others may have comprehensive web sites.  Stimulate the group to come up with all the venues that they think will work for their organization and then assign a small group to incorporate the ideas into the plan.

One more step in the starting week of implementation/upgrade planning.