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.

“Because you did such a great job with that last mess,
I’ve got another one I need you to handle!”

Sound familiar? Perhaps you’ve heard similar words from your boss in the past. Maybe you’ve said them to someone who works for you. Either way, they are symptomatic of a leadership problem that’s all too commonplace: unintentionally punishing good performance … giving the people we trust and rely on more work and more difficult or unpleasant tasks because they perform so well.

Common sense tells us two things about this subject. First, good performance should be rewarding, not punishing. Leaders need to do right by those who do right. Second, if team members experience negative consequences for doing good work, eventually they’ll stop doing it (or they’ll do less of it). That’s human nature … that’s obvious … that’s how leaders often shoot themselves in the feet!

So what’s the solution? That’s equally obvious! Don’t take your best people for granted. Keep things balanced. Avoid the trap of having one or two “go to” people who get all the tough and time-sensitive assignments – while their less productive teammates get to focus on routine, business-as-usual tasks.
Divide the work evenly. “Spread the wealth.”

Will there be times when you can’t do that … when your back is against the wall and only your best people can save the day? Probably so! But those instances should be rare. And when they do occur, make sure the rewards you provide far outweigh any downsides these truly special people may perceive.