How To Write A Simple And Effective User Story

This is a guest post by our friends over at the The Functional BA where they write about all things related to a career as a business analyst.

In today’s post, Stella, who is an IT Business Analyst with over ten years’ experience as a BA, project manager and process improvements, shows us how to write a simple and effective user story that we think you will find useful in your next sprint or software implementation.

With that, take it away, Stella!

A user story is a small, succinct statement of the functionality required to deliver value to a particular stakeholder.

They are used to document the needs of a specific stakeholder and enable teams describe valuable functionalities using short, simple statements.

They can also be used to identify the stakeholders’ needs and prioritize, assess, and plan solutions.

A user story is usually a sentence or two that defines which user’s need is being addressed, the goal the user is trying to fulfill, and any additional information that may be crucial in understanding the range of the story.

They are focused on stakeholder value and encourage further conversations with stakeholders.

User stories are also used to do the following:

Document stakeholder needs and rank the development of solutions.
Form the foundation for assessing and planning the solution delivery.
Form the basis for creating user acceptance tests.
Act as a criterion for assessing the value delivery.
Act as an element for tracing related requirements.
They are an input into project management and reporting.

So how do you write a good user story?

It might seem easy to write a good user story given their simplicity but there are a few guidelines that should be followed when writing a good user story.

Define the expected result: The user story is considered “done” when the stated task is completed. But in order to complete the task, the expected result has to be clearly defined so that the user knows the expected results.
Create sub tasks: If numerous steps have to be taken to fulfill the user story, then each of those steps should be created as subtasks in the user story.
Create user personas: If there are numerous end users in the user story, then you should create multiple stories for each end user instead of merging them all into a single user story.
A user story per step: a user story should be created for each step in a process, you should not merge all the steps in a process into a single user story.

A user story usually has the following structure

“As a [user persona], I [want to], [so that].”

But what does this mean?

User persona: this is the actor whose wants to accomplish something.

Want to: this is what the actor wants to accomplish.

So that: this is the why the actor wants to accomplish the thigh.

An example of a good user story is:

As a bank employee, I want to create a new customer account, so that the customer can perform their banking transactions.

Every user story should have clear acceptance criteria. Acceptance criterion is a set of conditions that are used to confirm when a user story is completed.

User story example: As a transit supervisor, I want to know the number of available drivers in the pool so that I can plan the bus schedules for the following week.

The acceptance criteria for this user story would be: The application should show the list of available drivers for the following week.

What are Epics: Epics are statements that are used to group a set of related user stories.

But how are Epics and user stories related?

An Epic: A user should be able to create and update their user profiles.

A related user story: As an application end user, I want to be able to create a new user account so that I can access the software application.

A related user story: As an application end user, I want to add profile photos to my user account so that people would be able to identify me.

A user story: As a business analyst, I want to limit the user’s profile picture size so that they don’t upload files bigger than 2 megabyte.

A user story: As an application end user, I want to have a field where I input a brief description of myself so that people can get to know me.

So, Epics are used to provide a summary of our goals and the user stories would break that epic into small, testable, achievable pieces of work.

To create a user story, you should ideally start with an epic and then break the epic into smaller, achievable chunks which become the user stories.

Good user stories should fulfill the INVEST criteria, which is:

Independent
Negotiable
Valuable
Estimable
Small
Testable

The user stories should be created from the user’s point of view, so if you are in doubt liaise with the user and then use their feedback to help create the user stories.

User stories have their strengths and limitations, which include:

Strengths

It is easily understood by the stakeholders.
It can be created through different elicitation techniques.
It is centered on the stakeholders’ value.
It allows the stakeholders to have a shared understanding of the need.
It is ideal for agile projects due to its small, implementable, and testable slices of functionality, which supports quick delivery and regular customer feedback.

Limitations

The requirements might not be detailed enough for the developers to properly implement.
The requirements might not be up to the organizational documentation standard or stakeholder expectations. So additional documentation may be required.

Conclusion

In summary, writing an effective user story doesn’t have to require a lot of effort…or time.

By following the steps outlined above, you can quickly write your user stories for your developers so that you can iterate more quickly and remove any of the early stumbling blocks that typically occur when developing software.

What the Arizona Cardinals Can Teach Us About Project Communication

By Carlos L. Aguilar 1 Comment

Just a heads up…have you downloaded our free PDF on the 10 steps you need to have a successful software implementation?

Click here to download now

Our family moved to the Phoenix area just over two years ago from Salt Lake City, Utah. Me being the sports buff I am, I was very excited to see there were FOUR major sports teams in the area:

Arizona Cardinals – NFL
Phoenix Suns – NBA
Arizona Diamondbacks – MLB
Phoenix Coyotes – NHL

In addition to these four teams listed above, there are also the following professional sports teams (although not as popular):

Phoenix Mercury – WNBA
Arizona Rattlers – Arena Football
Phoenix FC Wolves – United Soccer League (USL)

Since I’m a big fan of supporting local teams, we decided to become Arizona Cardinals season ticket holders (we are entering our second season).

We recently attended preseason game #3 versus the Cincinnati Bengals.

Here we are on the way to the game in the long line of cars waiting to park:

No tailgating in this HOT Arizona heat so we went straight to our seats to enjoy the air conditioned University of Phoenix stadium.

As the game started, the Cardinals offense looked sluggish — they couldn’t get anything going! Carson Palmer, the quarterback for the Cardinals, was off his game and missed connecting with some open receivers. The offense was looking like the Cardinals of the last few years: BORING.

SIDE NOTE: they had a great year last year and would have made the playoffs if it weren’t for the division they play in (NFC West).

Then, about midway through the first quarter Carson Palmer threw a pass intended for wide receiver Larry Fitzgerald. It was intercepted by Terence Newman of the Cincinnati Bengals.

Terence Newman returns the interception for a touchdown

Interception + touchdown = not good for the Cardinals.

Miscommunication? FOR SURE.

On this play Carson thought Larry was going to run a slant toward the middle of the field while Larry thought the route was for him to run straight up the field. Who was right, Larry or Carson?

After the touchdown the crowd moaned in agony as if to say “here we go again” as the Cardinals went on to lose the game 19-13.

Think team communication matters in sports? You bet it does. Does communication matter just as much when it comes to managing a project?

YES.

Had Larry cut to the middle, maybe the pass would have been completed and the Cardinals would continue their drive and maybe they would have scored. But we’ll never know.

The same can be said for projects lacking clear communication. Without clear communication, no one knows where to go or what to do. Interceptions are thrown, balls are fumbled and players are not in position to make a play.

If you manage projects, you know a large part of the project involves communication — up to three fourths of the project time. So yeah, communication is important and one of many keys to a project’s success.

Warning! Analogies ahead:

Not only that, communications is a core competency that when properly executed, connects every member of a project team (football players) to a common set of strategies, goals and actions (the game plan). But unless these components are effectively shared by project leads (football coaches) and understood by stakeholders (football owners and fans), project outcomes (results of the game) are jeopardized and incur unnecessary risk (like throwing the ball to a spot where Larry Fitzgerald was not present).

While football fans are stakeholders of the football team (since they invest money via purchasing season tickets), stakeholders from an organizational point of view are those who have a vested interest in the success of the project (like a VP of a business line or suppliers).

Poor communication can lead to budget overruns and missed revenue.

While it was only a preseason game, do you think the pass play by the Cardinals would affect the potential revenue stream for the organization if the interception prevented them from going to the Super Bowl? The organization would have missed out on a HUGE payday.

Monetary Impact of Poor Project Communication

Until recently, it was not clear how much of an impact ineffective communications has on project outcomes and subsequent business success. But a 2013 report by the PMI (Project Management Institute) revealed US$135 million is at risk for every US$1 billion spent on a project.

Further research showed 56% (US$75 million of the US$135 million) is at risk due to ineffective communications.

Dollars at risk due to ineffective communication — Source: Project Management Institute

While organizations are very aware of how critical effective communications is to the success of strategic project, and, ultimately, organizational success. However, the PMI report indicated only one in four organizations can be described as highly-effective communicators.

Not All Projects Succeed

You may already know this, but not all projects succeed. On average, two in five projects do not meet their original goals and business intent, and one-half of those unsuccessful projects are related to ineffective communications.

Project Failure — Source: Project Management Institute

How frequently you communicate, the content of your communication and the use of clear and relevant language directly affects the success of projects. In the graph below, project managers who communicated frequently regarding the business benefit, with the use of non-technical language, and sufficient clarity and detail had a greater than 80% chance of a successful project. Not bad, right? I would take those odds all day!

Frequent Communication — Source: Project Management Institute

How Do We Know if We Suck at Communicating?

At some point in your career you may have put on your resume: “excellent oral and written communication skills”. I know I did!

But do we really have excellent oral and written communication skills?

If we take a look outward and ask ourselves the following questions honestly, I’ll bet we find some gaps in our communication skills:

Do you feel everyone agrees with and supports what you say, feel and do most of the time?
Is there a lack of input, questions, or feedback on your ideas presented in meetings?
Are there few or no ideas presented in your meetings?
Do you have the inability to influence others to accept your ideas or change their viewpoint or behavior?
Are you seeing little or no behavioral change in the people you’ve coached for performance improvement?
Is there confusion about what is supposed to be done on a project?
Is there no understanding of the “why” behind the projects or goals you assign?
Are you nervous or hesitant about presenting new ideas to your boss, client, or strategic partner?
Is there frequent rework of the tasks you assign?
Do you have to constantly remind others to take action, meet deadlines or send information? (think about at home too)

If you answered yes to any one of those, your communication skills might be lacking. Truth is: we think are great communicators but we aren’t.

The Basics of Communication

Why do we make communicating with another human so difficult? It ought to be simple right? But it’s not and even I struggle with it.

Let’s have a look at some typical literary definitions of effective communications:

An exchange of information
An act or instance of transmitting information
A verbal or written message
A technique for expressing ideas effectively
A process by which meanings are exchanged between individuals through a common system of symbols

Here’s a visual representation of the basic communication process:

The words “encode” and “decode” should not be thought of as 128 SSL encryption nor Morse code. Rather, think about encoding and decoding as deciding what words you will use to communicate.

For example, as the sender you will find words in your vocabulary to best articulate and transfer information from your brain to the receiver’s brain (encoding). These words will then be “decoded” by the receiver and processed by their brain to try and understand the meaning of your message.

Obviously the words you choose must be meet the comprehension level of the receiver. For example, you wouldn’t want to explain quantum physics to a four year old because your encoded message would never be decoded (understood).

Couple the process above with body language and language barriers (for people who’s native language is not English) and it’s easy to see why humans are terrible at communicating with one another.

Which is why it is super important to choose the right language when communicating with others. In my opinion, plain speak is the best when writing emails and project plans but for whatever reason we think we need to sound highly intelligent and use big words to get our point across.

And it doesn’t help that in high school and college we are taught to write formally/professionally but have you noticed when you’re speaking to your friends and family you NEVER talk like that? So why do we write like that?

Recently, I purchased a great copywriting book by Neville Medhora. It’s a quick read with valuable information on how to write better. (You can get it here for $4USD)

In his book he touches on the point of writing with clarity, simplicity and avoiding ambiguous words to confuse and/or bore the reader.

Here’s the excerpt:

“Somewhere along the way we were taught to follow every grammar rule.
But why? The only point of writing is to communicate thoughts to someone (like I am doing now with you)
So if I write: Hey wat r u doin?
Even thought it is not “proper English” you still understand it as much as this text:
Hey, what are you doing?
In fact, the poorly formatted and mis-spelled version got the point across with less effort.
Just keep in mind, “Communication is just transferring information from one brain to another”
…And however we can do that best, should win.”

Notice the word “should”? It’s because some professions require technical and industry specific writing. For example, if you’re a rocket scientist at NASA your probably not allowed to write in a casual tone for your technical documents.

In fact, they even tell you how you will write when working for NASA. Here’s their guidebook for technical writers and editors (includes grammar, punctuation, and capitalization). If you’re absolutely bored out of your gourd, you can read the dry document here.

Then again, at NASA you know who your audience is right? Practically every person there is an engineer. So they speak engineer. Which is point #1 on things you can do to improve your communication skills.

Things You Can Do to Improve Your Communication Skills

Before you open your mouth or type the first sentence of an email, know who you’re speaking to. Is it the CFO? Is it middle manager? A supplier? A customer? Knowing who you are communicating with sets you up for success each time you write an email, prepare a presentation or make a phone call.
Know your audience.
1. It bears repeating: KNOW YOUR AUDIENCE
Practice writing.
1. To become a better writer guess what you have to do? Write! Set a goal to write more every day (start low with 250 words per day). Keep a daily journal. Write to your grandmother. Just write!
Write like a 6^th grader.
1. Unless you work at NASA
And I know in the corporate world you have to write corporate-y and use lame corporate-y buzzwords like: synergy, streamline, leverage, etc. But do everyone you work with a favor and AVOID using buzzwords. All they do is get in the way of the thought you are trying to communicate. The overuse of buzzwords can give the impression you really don’t know what you’re talking about. And, your audience tends to tune you out after the buzzword has just left your mouth.
Remember, all we doing is transferring information from one brain to another. Write with enough detail (but not too much) for your recipient to understand the message and write the message as simply as you can and with clarity.
Practice speaking in front of others
1. Speaking in public can be frightening for many. Jerry Seinfeld made famous the line about funerals and public speaking: “According to most studies, people’s number one fear is public speaking. Number two is death. Death is number two. Does that sound right? This means to the average person, if you go to a funeral, you’re better off in the casket than doing the eulogy.”
Get over your fear of speaking by joining a local toastmasters organization (toastmasters is a nonprofit educational organization that helps people improve their communication, public speaking, and leadership skills). They have clubs all over the world. Go here to find a local club.
Get out of your office or cubicle
1. For the love of Pete, get out of your office!
Sending an email is a cop out if the person you need to speak to is in the same building. Get out of your chair, walk to that person’s work area and talk. Such a novel idea! And guess what? Your message will probably be understood with more clarity than the email (emails are so often misinterpreted). There is also a bonus for speaking to someone in person: human interaction and the potential to develop a great working relationship.

The Palmer to Fitzgerald Pass [VIDEO]

Alright, at the beginning of this post I mentioned the interception of Palmer’s pass intended for Fitzgerald. Have a look at the video footage below showing the play in real time and slow motion. Who’s responsible for the error? Did Palmer call the play but Fitzgerald did not run the right route? Or did Fitzgerald run the correct route and Palmer was not aware of where he was supposed to be?

FYI, there is audio.

So…what do you think? Here’s the answer according to coach Bruce Arians, Carson Palmer and Larry Fitzgerald from arizonasports.com: According to Cardinals coach Bruce Arians, it wasn’t the quarterback’s fault.

“We had a miscommunication on a route,” Arians said. “The receiver should be breaking across the guy’s face, and he went behind him and it’s a pick-six.” Fitzgerald didn’t disagree with his coach. “I didn’t break across the corner’s face, and I’ve got to do that,” the receiver said. “You never can let your quarterback, you know, hang him out to dry, and so I’ve got to do a better job of reading and recognizing the defense and doing what I’m coached to do.”

Arians said it is the type of issue the team should not be having at this point in the season, but in reality, in roughly a week’s time the interception will be wiped from the record books like it never happened.

“It was just a miscommunication, something that doesn’t typically happen,” Palmer said of the pick. “It’s something that’s come up that’s good because we’ll look at it; we’ll see why that happened and we will move on and get better from it and learn from it. Of course, that does not mean Palmer will not (and has not) been criticized for the play — even though it wasn’t necessarily his fault — with Arians saying that’s just how things are in a quarterback’s world.

“That’s what it is in the quarterback’s world,” Arians said. “It is what it is.”

There you have it. Fitzgerald received the encoded message from Palmer but it looks like he did not accurately decode the message? But why?

Was it the words that were used (the encoding of the message)? Was it the body language? A lack of playbook knowledge? Only Palmer and Fitzgerald know the answer to this question. As a project manager, you are the quarterback.

Right or wrong, you will be the one to take the blame when someone on the team messes up. Just as it is in the quarterback’s world, so it is in the project manager’s world. What about you?

Do you have methods or advice on how to improve communication on a project? Let me know in the comments section, I love to hear different strategies and approaches on how to make the office a better place to spend half of your life.

Don’t forget to download our free PDF showing the 10 steps you need to follow for a successful implementation.

Click here to download now

10 Steps Your Software Implementation Should Have

By Carlos L. Aguilar 89 Comments

I’ve had a lot of people ask me how the Four Phase Training and Implementation Plan fits in within an enterprise software project.

To do this, I thought it best to take a moment to break down the anatomy of a large software implementation project.

But first, if you want to learn the EXACT process we used over and over to have a successful software implementation, I highly recommend you check out our playbook and resources that will ensure your project is a huge success.

You can learn more about it here:

VIEW THE PLAYBOOK

Alright, now let’s dive into the 10 steps your software implementation should have.

Below is a diagram that illustrates all of the major steps in a large software implementation project.

Read the diagram from left to right, top to bottom. For instance, the first circle is “Vendor Selection” and below vendor selection are the steps needed to complete the software vendor selection step.

10 Steps Software Implementation Should Have

Psst! Want this in a large, downloadable PDF?

Click here to download now

As you can see, there is a ton of effort put into a large software project. But did you also see where the Four Phase Training and Implementation Plan fits in?

The implementation plan commences at Process Refinement and ends at Month-End Support.

That’s almost the entire project.

I’m going to break down each one of those circles and also highlight the appropriate phase for each activity.

To provide some context and background, I’ll be referencing my guidebook to software implementations that explains exactly how to use the four phases along with some prerequisites and a cutover plan.

Step 1) Business Justification

Prior to doing anything on a software project, there has to be a definite business need, a solid value proposition, along with a gain or benefit after implementing the software. Typically this benefit will come in the form of a return on the investment (ROI) the company made to procure and install the software. The formula for ROI is as follows:

Since ROI is calculated in percentage, multiply this result by 100.

Example: let’s say a manufacturing company decides to implement new software. The estimated total investment for this software is $15MM USD. The anticipated cost savings (or gains) from implementing this software is $25MM USD. Therefore, the anticipated ROI for this project is 67%. I say “anticipated” because this calculation is based on assumptions and those assumptions may or may not happen.

Calculating the benefits of implementing software is always the first step; a business case, or justification, has to occur before anyone talks about buying new software.

Am I right? I mean, no company would go out there and just spend money willy nilly without having any idea of what the anticipated benefits would be would they?

With the business justification out of the way, let’s say top management likes the ROI and everyone gives the green light to proceed with the project. Who wouldn’t like a 67% return on a software investment for the company?

Step 2) Vendor Selection

With the business justification made and management agreeing to commence with the project, it’s time to select the software vendor. Epicor has a pretty simple process for selecting vendors and it closely mirrors my experience in how companies complete their selection.

Create an evaluation team. Assemble a team within the organization who will assist in the evaluation of the software vendor. This team should comprise of members from top management, functional experts and end-users. If you can find one, bring in a neutral consultant to help evaluate.

Business Assessment. Conduct an assessment of the current state of the business. Look at critical processes and note what is being done well and what benefits a new system can deliver for these processes.

Software Criteria. Develop a selection criteria to evaluate the available solutions. Criteria can include features, price, platform, and anything else the evaluation team can think of. Group the criteria according to importance to your business, i.e. very important, important, and less important. Assign a score (such as 1-5) to each to make the evaluation easier.

Some of the criteria can include:

Industry Expertise. How well does the ERP vendor understand your industry? Does the vendor offer industry best practices or pre-deﬁned processes that are generalized or horizontally focused? ERP solutions should at the very least address your mission critical business requirements speciﬁc to your industry.
Total Cost of Ownership (TCO). Determine the long-term TCO for hardware, software, and support—pre and post implementation.
Multi-Site Operations Support. If you need to collaborate with multiple operations then ensure your ERP vendor can support multi-site operations. Can your ERP vendor support all your locations with a small centralized IT staff? Do they require complicated architectures?
Customer Support. Does the ERP vendor have its own in-house support or does it outsource? You’ll gain the most out of your investment if you have access to a customer care center that can answer your key application and technical questions and advise on best industry practices

Ask for specific references. Don’t let them send you a list of “pre-screened” references who will surely tell you all the great things about this particular vendor. Instead, ask them to provide references of companies who are in the same industry as yours and faced similar business challenges. If desired, ask to visit these customer to see what they like and dislike about the software and whether or not it is working as expected.

Step 3) Project Kick-off

With the vendor selected, it’s time to get the project started with a good kick-off! The first part of kicking off the project is to assemble the team. This will take some time and is a crucial step in the implementation process.

This is the time to identify key resources to oversee the project and ensure its success.

Governance structure. To ensure accountability and success of the project, a governance board or steering committee needs to be put in place. This purpose of this committee is to help the project sustain its potential to deliver its promised value.

The committee must also help managers assess the project’s current state and adjust content and direction if necessary. They should also allow management to refine the definition of success to maintain alignment with evolving business strategy.

Typically this committee is comprised of the project manager, project sponsor, project management office (PMO) and most importantly senior business unit managers with a vested interest in the success of the project. The last group is important because they will be representing the users within each function of the company.

Executive sponsor. An executive sponsor is a C-level administrator who has a vested interest in seeing a project to completion.

Ideally, the executive sponsor should be the highest-ranking manger possible, relative to the size of the project. Successful sponsorship requires a deep understanding of organizational culture and awareness of how the project will help the organization achieve its goals. Part of the sponsor’s job is to promote the project within the organization, making sure everyone understands the benefits the project will provide.

In some organizations, the executive sponsor is the person who is responsible for financially authorizing a project and creating the project charter. The sponsor should work closely with the project manager, but is probably not the project manager’s boss. Typically, the project manager is responsible for day-to-day execution and the sponsor only steps in to make decisions when change requests might affect the project’s scope.

Project Management Office (PMO). The primary goal of a PMO is to achieve benefits from standardizing and following project management policies, processes and methods.

For the software implementation project, they will be the source for guidance, documentation, and metrics. If necessary, they will get involved with project-related tasks and follow up on project activities through completion. They may report on project activities, problems and requirements to executive management (CEO, CFO, CIO, etc.) to keep these decision makers moving toward consistent, business focused goals and objectives.

Project Manager. The individual responsible for the project’s overall performance and success. He or she will liaise between the functional/technical leads and the PMO/Project Sponsor/Steering Committee. It is a huge role and filling this position should be a collaborative effort within the organization.

Functional Leads. Don’t underestimate the value of your functional resources on a software implementation project. Choose the wrong resources for this role and risk not having the business requirements translated to technical requirements for the software.

Recruit people within the organization. Make sure they have at least the following: leadership, management, strong communication skills, charisma, knowledge of software systems, ability to write clear documentation, likes to help others and wants to see the project and company be successful.

Technical Leads. If you can source these individuals within the company, do so. Otherwise, vet these candidates with the same scrutiny you would for your functional leads. Ask for examples of work. Talk to references. Allow the functional leads to participate in the interview process since both teams will be working together closely for months to come.

Change Management. This could either be an individual or a team — depending on the scope of the project. Having a change manager on the project is not required but might be depending on organizational culture and number of users affected by the implementation.

The role of a change manager for a software project is to increase employee adoption and usage of the software by applying a structured methodology.

As previously mentioned, utilizing the four phase training and implementation plan I’ve developed has proved to increase employee adoption and usage through a structured method. Incidentally, the plan itself acts as a change manager within the organization during the project.

Prior to announcing the project to the organization, the CEO ought to get the entire project team together to: a) announce who is filling each role on the project b) allow the team to meet each other c) motivate the team and d) set expectations of the project team

Announce to Organization. With the project team assembled, It is time to announce this endeavor to the organization! This kick-off and announcement to the organization should be held like the opening of the Super Bowl.

Get as many employees together as you can, set up a common area, serve food, play music and end it all with a kick-ass motivational speech by the CEO. Make it special for the organization.

Do this and both the project team and employees will be energized to make the project successful.

DON’T simply send out a BORING memo! No one will be excited and energized by a memo.

Step 4) Process Refinement

With the project kicked-off, it’s time for the project team to get to work! Send out the functional leads to meet with the business process experts and start identifying all business processes to be included in the software.

Work with these experts and other superusers to analyze the processes to see if any improvements can be made to them. Can you modify a step in the process to make it more efficient? Does this process touch other parts of the business? How critical is this process to generating revenue or satisfying customers?

Once the processes have been identified and scrubbed/reengineered, it’s time to document. Again, keeping it simple, just create the process like so:

Step 3 corresponds to the “Prerequisites” phase in the Training and Implementation Plan

Step 5) First Software Build Out

After refining the business processes, it is time for the first software buildout. This is where the functional leads transfer the business requirements to the technical team and the technical team begins the work of programming and configuring the meet the business needs.

Keep in mind this first build out should be largely representative of what the company needs to do to keep the business running. Depending on timelines and/or constraints, the software may only be 85-90% built with the remaining to be completed before User Acceptance Testing (UAT).

Step 4 corresponds to Phase 1: Face to Face Training of the Training and Implementation Plan

Step 6) Conference Room Pilot’s (CRP) and Software Configuration

With the first buildout of the software completed, it is time to validate if the team is on track with its configuration of the software.

In a large software implementation there will be three CRP’s. For the first CRP, get all of the Subject Matter Experts (SME) together along with other business process experts and superusers. Talk about each business process and how they were transformed to reside within the software.

Demonstrate the process in the new software then allow the users to complete the task individually. Be sure to provide a job aid and data sheet for each process to be tested so each user knows where to click and what the expected results are.

Note all of the passes and fails of each step and also be sure to note any lack of functionality, software bugs or key usability issues. Make sure both the functional team and technical team are facilitating these sessions.

Software configuration. Based on the issues discovered during CRP1, make a list of the top 10-15 critical items to be fixed before the next CRP session. Have the technical team make all of the necessary fixes and bug squashing.

Rinse and repeat.

Conduct a second CRP session with the users and note the passes and fails of each step along with any lack of functionality, software bugs or key usability issues. Make appropriate changes to the software application.

Rinse and repeat.

Conduct a third CRP session with the users and note the passes and fails of each step along with any lack of functionality, software bugs or key usability issues. Make appropriate changes to the software application.

Due to the duration of Step 5, this step corresponds to Phase 2: Mini-CRP and Web Calls and Phase 3: Monthly Proficiency Tasks of the Training and Implementation Plan

Step 7) User Acceptance Testing (UAT)

With three CRP’s completed and multiple configurations made to the application, it is time to demonstrate the software is ready for the users. With the incorporation of Phase 2: Mini-CRP and Web Calls, iterative changes can be made without the need of a full blown CRP. Therefore at this stage in the project the application should be ready for enterprise use.

Conduct a thorough end-to-end testing of the software with every business process from every function of the company.

As with CRP sessions, ensure job aids and data sheets are used during the testing. Every end user should attend this session in person.

After the system has been tested by the users, you may formally or informally have them “sign-off” on system readiness.

However, should there be any issues uncovered during the UAT, complete one final round of software configuration before go-live.

Step 6 corresponds to Phase 4: Final User Training and Certification of the Training and Implementation Plan

Step 8) Cutover

Time to begin the process of transitioning from one system to a new one. The organization needs to plan, prepare and execute the cutover, by creating a cutover plan to describe all cutover tasks to be completed before go-live. This plan is designed to minimize the ongoing risk of moving from one system to another.

It also includes the task of migrating code from a development or test instance to the production instance.

Once these activities have been identified, they become tasks assigned to key stakeholders of the project. These stakeholders can be anyone from a project lead to a controller who has to ensure the books are reconciled prior to moving to the new system.

When developing a cutover plan, identify key activities well in advance so the project team and stakeholders can agree on the tasks and be aware of when they need to be completed.

Examples of cutovers tasks are:

Prepare production environment
Date for last transaction in old system
Data conversions
Complete final month end close in old system
Preparing the Service Desk for user support
Setting up a command center prior to go-live
Developing a user support plan

Also ensure there is a contingency plan in place should something go wrong during the cutover process; no need to shut down business operations.

Ensure there are checkpoints along the way and communicate the passing of each item on the list.

Step 7 corresponds to the “Cutover” section of the Training and Implementation Plan

Step 9) Go-live

The big day is here. Time to “turn-on” the new system and allow users to transact.

I’ve said this many times but it still bears repeating: every software project needs to deploy the functional resources to key locations to provide on-site support at go-live. Providing in-person support for the users at go-live is a morale boost for the organization and is vital to the success of the launch.

Step 9 corresponds to “Supporting the Organization” section of the Training and Implementation Plan

Step 10) Month-end Support

As with go-live, deploy the functional resources to key locations to provide on-site support at go-live. Providing in-person support for the users provides a huge morale boost. Send key personnel to sites a couple of days before month-end and have them return just after the close.

Step 10 corresponds to “Supporting the Organization” section of the Training and Implementation Plan

Post Mortem: Project Closure and Lessons Learned

Project Closure. With the software fully launched and business returning to normal operations, the project manager will complete a final checklist resembling something like this:

All deliverables accepted and signed off by client or sponsor
Final project status reports complete
All financial processes and reports complete
Project review complete
Staff performance evaluations and reports completed
Staff employment on project terminated or reassigned
Announcement of completion of project (internal, external and public relations contacts)
Completion and storage of project file

Lessons Learned. Use Google Forms to create an online questionnaire to solicit objective responses from the project team.

Categories should include the following:

Management Sponsorship
Project Objectives & critical success factors
Project Plan and Schedule
Project Team
Client/End User Involvement
Use of Technology
Project Monitoring
Project Communications

Allow space under each topic and create questions to be answered on a scale like this:

0 = Don’t Know or Not Applicable

Scale from 1 to 5

Where 1 = Strongly Disagree

And 5 = Strongly Agree

In conclusion

Friends, I hope this clarifies where the Four Phase Training and Implementation Plan fits within a software project.

What does your software project’s structure look like at the moment? Is it similar?

Leave a comment below as I love learning how others manage their projects.

16 Strategies to Fend Off User Resistance

By Carlos L. Aguilar 1 Comment

“Innate resistance to change, lack of involvement in the implementation process, lack of management support, poor technical quality which makes the system appear ‘unfriendly’, and the lack of interaction between the designers and users…all of which will contribute to the demise of a software project”

It’s a fact: some people like change and others don’t. And we also know this about change: it is inevitable. Everything around us is changing right this moment. The change might be gradual but it is happening.

Just Released: a super helpful diagram to assist you with your next software implementation. It shows all 10 steps needed to be successful.

Click here to download now

A change not so gradual is a software implementation. Compared to how slow changes take in our lives, implementing new software is a rapid change. Maybe this is why so many people don’t like new software implementations within the company — the change is too much at once.

But that’s just one of the many reasons people resist a new software application.

It’s also just one of the many ways your project can get derailed. In this blog post, we’ll examine why users resist adopting to new software and what you can do to help get them on board.

Types of Resistance

Resistance to the new system will fall into the following categories: active resistance and passive resistance.

Active resistance is openly questioning the reasons for bringing in new software. Also communicating to others a lack of the underlying need for making a software change in the organization.

How to spot people actively resisting the system: you’ll see them chatting with co-workers and voicing their opinion against the new system. They will try to get others to rally and join the cause. In more extreme circumstances, he or she may leave the organization in protest to the new system (the same way in which Jerry Maguire made his legendary exit).

Passive resistance is a little more difficult to detect and may take time to uncover those who are passively resisting the system. Why? People may actually express support for change, but when change is getting closer to being implemented, resistance starts to come through.

How to spot people passively resisting the system: users who are “faking” their way through the project. These individuals may seem happy to see you and willing to use the system but once you turn your back on them, they quietly undermine the project’s success. Make strong connections with your superusers/subject matter experts and rely on them to provide you with intel on the passive resisters.

Strategies to Overcome Resistance to the New System

In a moment I’ll list some of the common things to look for during an implementation which contribute to user resistance.

But before doing so, we need to cover two types of strategies to help you conquer user resistance.

James Jianga, Waleed A. Muhannab and Gary Kleinc conducted research on user resistance and how to promote acceptance of the system. To overcome resistance, researchers have proposed a variety of strategies, which can be classified into two categories: participative and directive.

Participative strategies include:

Training in the use of the new system
Establishing user support services
Allowing time to experiment with the new system
Praising new system use
Encouraging open communication between management and employees
Incorporating user participation into the design process
Documenting standards for the new system

If you’re a consultant or project manager working on a software implementation project right now and you haven’t included any of these strategies, you had better sit down and figure out how you’re going to apply as many of the strategies as soon as possible. User participation is priority 1.

Directive strategies include on the other hand, are those imposed by management:

Provision of financial incentives for new system use
Job reassignment
User rights directives
Role modifications
Job elimination for those who do not learn to use the new system
Power redistribution
Top management support
Job title modification
Job counseling

If you’re a manager at a company implementing new software, time to do some assessments on your organization. Be sure to meet with your project leads and/or consultants to get a feel for how people are reacting to news of the new application. Also be sure to have the project leaders identify any users who are either passively or actively resisting the system.

Top Reasons for Resisting the New System

Let’s have a look at some of the top reasons people resist switching to the new software system and see which types of strategies we can apply to help us overcome user resistance.

Love for the legacy system

Are users still lovin’ on the legacy system? You know, the old one you’re trying to replace?

It’s very common to have people latch on to something familiar while rejecting something unfamiliar to them (the new software system). Especially if you have had this old system in place for a long time.

But to steal a line from the popular Semisonic song Closing Time, “Every new beginning grows out of some other beginning’s end.”

When it comes to transitioning to the new system, it’s best to severe ties with the old system ASAP. As in the day you go live with the new system, the old one gets shut down.

You might be asking how you fix data in the old system if it is turned off? I mentioned cutover in this blog post as something needing to be well planned in Phase 4 of the training and implementation plan.

You’ve got to have a solid cutover plan to be able to leave your legacy system behind.

Send your last invoice from the old system. Ship the last customer order from the old system. Close the books one more time in the old system.

LET IT GO

If there’s an invoice or customer order needing to be fixed after you have transitioned to the new system, you’ll have to make the fix in the new system.

Personal Story: when I was rolling out Oracle Projects, there were some invoices sent in the old system but the customer came back to us and told us there was an error on the invoice to be corrected.

To do this, we had to first cancel (void) the invoice in the old system. Only a handful of people in accounting still had access to this legacy system and we had to work with them to get it voided.

Afterward, we created the correct invoice in the new ERP system and sent the revised invoice to the client.

You have got to have this type of plan in place when you cutover to the new system.

But what about people? How do you get them to let go of the old system?

Participative Strategies to apply to this situation: Training in the use of the new system, allowing time to experiment with the new system, praising new system use, encouraging open communication between management and employees and incorporating user participation into the design process.

Specifically, start creating proficiency tasks to encourage system use and familiarity. Then praise those who have successfully completed the tasks. Also begin conducting monthly web meetings and status calls to encourage open communication between management and employees.

Directive Strategies to apply to this situation: Provision of financial incentives for new system use, job reassignment, user rights directives, job elimination for those who do not learn to use the new system, top management support, job title modification and job counseling.

Without being privy to the situation, these directive strategies will be at the discretion of the management team and the employee’s direct manager. Everyone involved will want to work closely Human Resources to ensure everything is being handled appropriately for some of the more stringent strategies being applied.

A General Loathing for the New System

A user’s resistance to change from a system they have used for years can quickly turn into a roadblock during your implementation. This usually happens because the processes involved in the new system are very different from the legacy system.

Darth Vasder: It is useless to resist change

Especially when implementing ERP behemoths like Oracle and SAP.

The new system may require accessing additional screens, more mouse clicks, etc. When it comes to an ERP system, it uses a centralized and integrated database with more controls on processes, thus needing more checks, interlocks and database postings, when compared to the old system.

This gives the impression (or it just might be true) the ERP system is slow and users, who may already be resistant to the change, often start complaining.

So how do we handle this situation?

First let’s look at why the user is being resistant to adopting the new system. Here are some common reasons along with an explanation:

Reasons for Resistance	Explanation for Resistance
Parochial self-interest	Resisting change to prevent losing something of value
Misunderstanding and lack of trust	Misconceptions about the implications and insufficient information of the benefits and gains
Different assessment	Employees see more costs than benefits and those initiating the change see the reverse as true
Low tolerance for change	Fear of not sufficiently developing the skills and behavior required
Increased efforts	Additional efforts or abilities needed for the job

Where does your particular user(s) reside in the table? Once you have identified the reason and the explanation work on getting him/her back on track.

Participative Strategies to apply to this situation: Training in the use of the new system, establishing user support services, allowing time to experiment with the new system, praising new system use, encouraging open communication between management and employees and incorporating user participation into the design process.

Again, start creating proficiency tasks to encourage system use and familiarity. Then praise those who have successfully completed the tasks. Also begin conducting monthly web meetings and status calls to encourage open communication between management and employees.

Directive Strategies to apply to this situation: Provision of financial incentives for new system use, job reassignment, user rights directives, role modifications, job elimination for those who do not learn to use the new system, top management support, job title modification and job counseling.

Anytime you feel the need to “lay down the law” with these directive strategies, be sure to include appropriate management and human resources when applicable.

Often you’ll see users who have been in the legacy system for some time being the ones giving you grief.

Depending on the person you could expect red herring excuses when these users are confronted with their lack of user adoption. These are your passive resisters.

Be prepared to put in extra effort with these resisters in order to get them to support the new system. With some persuasion and extra coaching, most of them can be brought around.

Recognize you are probably going to have a few hold outs who will only respond to the stick side of a carrot and stick approach. You need to be supportive of people going through the change, but not at the expense of jeopardizing the project.

An ERP study by Sayeed Salih, Ab Hussin and Halina Dahlan from Universiti Teknologi Malaysia revealed 55.8% of users indicated a lack of user training and education as the reason for resisting the change the new system.

Their study also showed the relation between the knowledge transferred by the ERP consultants during and after implementation to the end users and a 10 step process could solve issues for user resistance.

Keep in mind user training should not be limited to the system features. It should serve as a need to educate users about the system and how they contribute to it.

Always operate with this in mind: how will this affect my users? Will this feature enhance the user experience or allow them to be more efficient in their job?

When it comes to software it is ALWAYS about the user.

Not involving users in the design phase

Often organizations do not involve key users during the implementation process or seek their active support before embarking on a software implementation. If you’re not involving the users early on in the design (or build-out) phase, you’re just asking for trouble.

When conducting software implementations there are “Prerequisites” to be completed. One of them is meeting and learning from the experts in the organization — the business process experts. When you meet with them, the goal is to sit down and document all the business processes this expert is responsible for.

Then build a test instance of the software you are launching to validate the configuration meets the needs of the users. This gives them time to experiment with the new system.

And you are getting key users and stakeholders involved early and often. If a new system is implemented like a routine software upgrade, then it will only result in a half-hearted acceptance of the system.

Big ERP implementations require lot of pre-implementation activities like: process modeling, process mapping, etc. These activities require extensive interaction with key users.

It not glamorous, nor fun, but it’s GOT to happen. These are very critical steps to the success of your software launch.

Participative Strategies to apply to this situation: Allowing time to experiment with the new system, encouraging open communication between management and employees and incorporating user participation into the design process.

If you’re working on a project and have not involved any users in the design process, stop what you are doing and go meet with the appropriate individuals.

And when documenting the processes, keep it simple. Like this:

Simple Process diagram — Keep process diagrams simple…more people in the organization will understand how things work.

Directive Strategies to apply to this situation: N/A.

In this case, there are no directive strategies to apply from a management standpoint. This issues is to be resolved by the project team.

Lack of top management participation

In all of my findings on software implementation failures, this reason always sits at #1.

There’s just no way around it: a lack of top management support will prove to be fatal for your software implementation project.

It’s pretty simple. If management is not going to support the new system why would the users? People will either see, or get word, management is not 100% on board and no one will bother to participate in the project.

Why doesn’t management support a software project? Often a software implementation project is seen as an IT project rather than a business project and as a result, top brass of the organization refrain from actively participating in the implementation process.

This is why an IT driven implementation is sure to fail.

In smaller firms it’s not as prevalent simply because the CEO is closer to ground operations and thus has an interest in seeing the project succeed.

With larger firms, it’s important to monitor how meetings and corporate communications are being handled (email, TV, blog, posters, etc). This usually provides insight to how well the project is being supported. If it’s like crickets in the organization, then there’s a problem. What strategies can applied here?

Participative Strategies to apply to this situation: Training in the use of the new system, establishing user support services, allowing time to experiment with the new system, praising new system use, encouraging open communication between management and employees, incorporating user participation into the design process and documenting standards for the new system.

The list may seem like something you’ll do for the users but you’re actually going to apply them to the management team. How? By showing them exactly how you plan to do each one of the listed strategies during the project. With management knowing they have a solid plan in place, they will be more likely to support the initiative. Do this early on. As in yesterday.

Directive Strategies to apply to this situation: N/A.

However, you could potentially do the same thing as the participative strategy if you are asked “what will you do if users resist?”

In reality, top management needs to be properly engaged early on so they can “sell” the project to the rest of the organization.

If they aren’t selling for you, then you have a tough road ahead. But all is not lost.

There are two things you could do immediately if you’re in the midst of a project and management still hasn’t bought in:

Revisit your project plan and make realistic changes to it. If there are resources unavailable or interruptions in the timeline, make changes and notes
Have a forum/venue to share this updated plan (like a steering committee or governance board meeting)

This is the forum you should use to raise issues around resource availability and to highlight any negative effects on the project.

Why? The steering meeting is typically attended by the project sponsor (who should be one of the senior management team). The role of the sponsor is to support the work of the project manager and to assist in the resolution of contentious issues.

This is where honesty and integrity come in. Be absolutely clear with them as to what is going on with the project so a solution can be found.

Side note: If you’re part of top management or can influence top management, here’s a reference table of “what not to say” during an implementation.

Do Talk About	Don’t Talk About
Larger deals/contracts	Higher productivity
Happier customers	Tighter management
Less wasted effort	Automation
Improving business processes	Job elimination
Achieving goals easier	Leverage
Giving employees tools they need to succeed	All-inclusive system

If employees get the feeling you’re bringing in new software to unify the company and make it more coherent and coordinated, they will follow your example.

But if they sense you’re going to use the system to lay blame or fuel political battles, they will subtly sabotage the system as they would any enemy. Instead, celebrate the small wins you are accomplishing while rolling out the system.

Don’t try to do everything at once. This will overwhelm the organization and more importantly: the end-users. Without the support and engagement from the end-users the implementation will fail before it ever began.

Over Promising on Software Features

And under-delivering on them? Yikes.

At least 50% of all ERP system implementations do not meet expectations, and one third are utter failures.

Any user will resist software delivered with the promise of goodness and benefits yet when they use it for the first time, they discover it has neither.

No one likes broken promises.

Like top management buy in and involving users in the design phase, this should be handled early on in the project. This is when those business processes get mapped or reengineered and then the software is closely matched.

During your time with the users, be aware of scope creep.What is scope creep? It’s when we can’t say “no” to features the end users want. Rather than focusing on the critical features and getting them out the door, we say yes and continue to build and test and build and test and then delay the rollout and/or fail altogether.

If you’re keenly aware of scope creep, you can avoid over-promising on features.

Participative Strategies to apply to this situation: Allowing time to experiment with the new system, encouraging open communication between management and employees, incorporating user participation into the design process and documenting standards for the new system.

Employ these strategies from the get-go and you’ll find the implementation of your software will go a lot smoother.

Directive Strategies to apply to this situation: N/A.

This is a project team responsibility. Always be clear to the users about what to expect with the new system. If you are ever asked if the software will be able to do “this” or “that” simply say “Great idea! Let us look into adding this feature and we’ll get back to you”

If the software can’t do it, it can’t do it. Perhaps a different application should have been selected. Otherwise pay a ton of money to have someone create a custom enterprise application to meet your “unique” business needs.

Poor planning and time management

This is never good for any project. Any poorly planned software implementation will surely encounter user resistance. If it’s poorly planned, either the go-live date will be accelerated or pushed back. What I have discovered is companies often tend to be intimidated by the time and money required for an implementation and then look to accelerate the go-live date to offset these misunderstood costs.

Without the right strategy and tools, implementation acceleration has the risk of inadequate end user training, an ineffective change management strategy, reduced reengineering of business processes, and other problems lead to higher overall cost of ownership and the erosion of benefits from the new system. It’s negating the purpose of implementing the software in the first place.

On the other hand, extending the implementation period has its own share of drawbacks.

Excerpt from a client: “We have taken a very long cutoff period for implementation, i.e., we have decided to go live in August 2012 instead of doing so in April 2012. To do this we had to backdate the server, and adjust some stock transactions, accordingly. However, this is now proving to be a major challenge while reconciling accounts.”

Often when a go-live date gets pushed out, it’s not a good sign. And if it’s because project personnel need more time, then it’s a personnel/resource issue and not a software issue. You might have to look at your resources.

Strategies to apply in this situation? None of the above. Both participative and directive strategies infer there is a functioning instance of the software. If the implementation has been poorly planned, is there a functioning instance to which these strategies can be applied?

Instead, conduct a thorough risk analysis on the project and especially scrutinize the critical business processes. Start with those and ensure they work. Maybe the organization can live without other parts of the business not operating for a certain period of time.

Or see if there are temporary work-arounds you can implement to keep parts of the business running while things get fixed. It may even have to be something manually tracked in Excel and then later put into the system either manually or through a data load.

To avoid this in the future, be sure your implementation is done incrementally and in a phased manner.

Your Story

What about you? What kind of user resistance have you encountered and how were you able to overcome it?

Why SAP and Oracle are Taking Usability Seriously

By Carlos L. Aguilar 2 Comments

What You’ll Read In This Article:

Usability means users need to be able to complete their tasks quickly and with freedom of discomfort and a positive attitude towards the use of the product.

Heuristics:

Nielson’s heuristics provide the foundation for evaluating ERP user experience. It means enabling a person to discover or learn something for themselves.

User Interviews:

Researchers from Bentley University share users’ opinion on ERP software. Here’s what one had to say: “I feel like it’s an impassive, sometimes uncooperative, coworker.”

New Features in ERP:

We’ll look at some features that SAP and Oracle have released or are working on releasing. But will it be too little, too late?

Usability of ERP software has come to a tipping point and the “big two” (SAP and Oracle) are racing to make changes to their user interface. Smaller, agile, and user-friendly ERP software companies are biting into their market share and have shown significant revenue increase in recent years.

Usability, or lack thereof, has been a thorn in the side for many companies over the years. It’s hindered efficiency and user adoption in the organization. Companies have sacrificed this inefficiency and adoption in exchange for integrating business processes and getting everyone in the organization to use the same platform.

Frustrated — This guy is angry at his ERP software

But that only goes so far. As a new generation of people enter the workforce, a generation groomed on friendly apps and slick devices from Apple and Google, their tolerance for such unfriendly interfaces will be small.

Something has to change.

Most ERP systems, such as SAP and Oracle, are built on a three-tier architecture: the database layer, the application layer, and the client or user interface layer.

These tiers are also widely known as Data, Business/Logic, and Presentation layers. These ERP applications are commonly deployed in a distributed and widely dispersed manner.

While the servers may be centralized, the clients are usually spread to multiple locations throughout the business.
Historically, software developers have focused most of their effort on ensuring that the data and business/logic layers of a system were stable and functional, with less focus on the presentation/user-interface layer.

This is particularly true of ERP systems where, as the business’ system of record, the absolute reliability of the data and application logic necessarily take precedence over ensuring a simple and efficient user interface.

Which means, “Houston we’ve had a problem.”

What is Usability?

Usability is at the core of how software applications are designed and distributed to the masses for use. It plays a critical role in the success of e-commerce websites and the thousands of applications launched each week in the App Store.
To elaborate, usability is the ease of use and learnability of a human-made object. In the computer world, the most widely accepted definition comes from the ISO standard 9241-11. It defines usability as the “extent to which a product can be used by specified users to achieve specified goals with effectiveness, efficiency and satisfaction in a specified context of use.”
Simply stated: users need to be able to complete their tasks quickly and with freedom of discomfort and positive attitude towards the use of the product. Which is what we, as end users of any app or website look for. But does your ERP system do this?

Heuristic Evaluation

When software developers and designers create software, they must also take into account the heuristic evaluation, or usability inspection, that helps identify problems in the user interface design. What is the definition of heuristic? Heuristic can be defined as: enabling a person to discover or learn something for themselves.

Jakob Nielsen’s heuristics are probably the most-used usability heuristics for user interface design. Nielsen developed the heuristics based on work with Rolf Molich in 1990. The final set of heuristics that are still used today were released by Nielsen in 1994. Let’s look at each of Nielson’s heuristics in detail, as in his book Usability Engineering:

Visibility of system status

The system should always keep users informed about what is going on, through appropriate feedback within reasonable time.

Example: If it takes a long time to load a screen, display a progress bar and/or an estimate of the time it may take to load, so users know what to expect.

Match Between System and Real World

The system should speak the users’ language, with words, phrases and concepts familiar to the user, rather than system-oriented terms. Follow real-world conventions, making information appear in a natural and logical order.

Example: When designing a website for children, use terms with which they are familiar and display information in formats they are used to seeing.

User control and freedom

Users often choose system functions by mistake and will need a clearly marked “emergency exit” to leave the unwanted state without having to go through an extended dialogue.

Example: Provide the functionality to Undo and Redo actions and to easily exit the system.

Consistency and Standards

Users should not have to wonder whether different words, situations, or actions mean the same thing. Follow platform conventions.

Example: Use icons with which people are familiar, rather than creating new designs that mean the same thing.

Error prevention

Even better than good error messages is a careful design which prevents a problem from occurring in the first place. Either eliminate error-prone conditions or check for them and present users with a confirmation option before they commit to the action.

Example: If a user cancels her account, offer her a way to re-establish the account within a certain time period.

Recognition rather than recall

Minimize the user’s memory load by making objects, actions, and options visible. The user should not have to remember information from one part of the dialogue to another. Instructions for use of the system should be visible or easily retrievable whenever appropriate.

Example: On a web form, allow easy access to previously entered information, such as serial numbers, so the user does not need to recall the information or write it down.

Flexibility and efficiency of use

Accelerators — unseen by the novice user — may often speed up the interaction for the expert user such that the system can cater to both inexperienced and experienced users. Allow users to tailor frequent actions.

Example: An accelerator can be a keystroke shortcut, such as Macintosh’s Command+Q to quit an application.

Aesthetic and minimalist design

Dialogues should not contain information which is irrelevant or rarely needed. Every extra unit of information in a dialogue competes with the relevant units of information and diminishes their relative visibility.

Example: Background graphics can make viewing text difficult.Help users recognize, diagnose, and recover from errors

Error messages should be expressed in plain language (no codes), precisely indicate the problem, and constructively suggest a solution.

Example: If the user enters an invalid email address on a web form that requests the address, the error message could read, “That email address is not in our records. Please enter an email address in this format: email@address.com.”

Help and documentation

Even though it is better if the system can be used without documentation, it may be necessary to provide help and documentation. Any such information should be easy to search, focused on the user’s task, list concrete steps to be carried out, and not be too large.

Example: If there is not enough reason to produce an entire Help section, and there are a couple form fields that may be confusing to some users, it is appropriate to include “in-line help” in the form of a link that opens a a small help dialogue next to the form field. Alternatively, next to a form field text box or field label, provide users an example of how to input the information using the required formatting, such as entering a phone number as xxx-xxx-xxxx.

Real World Examples vs. Nielson’s Heurisitcs

[quote] I feel like it’s an impassive, sometimes uncooperative, coworker.[/quote]
Keeping Nielson’s heuristics in mind, lets’s examine how some ERP systems perform against these heuristics.
Researchers from Bentley University conducted interviews with 33 end users at three organizations in a northeastern U.S. State in 2010. These organizations used different ERP systems (software name not revealed) and the users had varying levels of system experience. While these interviews are a few years old, the information is still relevant today. Just as there are hundreds of companies running unsupported Windows XP, there are thousands of companies still running ERP software that was released as far back as 2000. Oracle’s current ERP release (R12) was released in 2007.

The interviews below reveal the link between collaboration and usability of the system by demonstrating the absence of key properties and violations of Nielsen’s heuristics.

In theory, ERP systems are designed to assist users. The shared goal between the system and user is often equivalent to the user’s goal (like billing a client). Hence, it is important that the user know what the business goal is before performing any task. Here is an excerpt from a superuser:

User 1: “And the first thing is to forget about the system for a sec. Keep your keyboard away, discuss as a group, individually, collectively, whatever, what you are trying to do conceptually. Then execute.”

I’ve witnessed this during my Oracle implementations where key stakeholders from the business took part in the initial system design. The business process has to first be defined, then the system was designed to meet this business process (read: custom code).

Even though users know the business goal and the logical steps in the plan for achieving it, those steps may not be easily mapped to the functions provided by the ERP systems. The intrinsic complexity of the interrelated business processes coupled with complex interfaces makes it difficult for users to perform a very simple action, like locating a function.

User 2: “It (the system) doesn’t tell you what steps to take next. You have to basically know what the next step is for your process, for what your job title is to do.”

As a result, users spend a significant amount of time in training, communicating with colleagues, and using trial and error approaches to learn the steps for their tasks. These steps are described by users as “unintuitive,” as they often do not match the logical steps that users associate with the business processes. As a result, users frequently create “cheat sheets” that document the procedures and steps required for a task. With practice, users may no longer need these notes, but they continue to rely on them for performing non-routine tasks:

User 3: “I have a little checklist, so when I do ACH payments, I just have screen charts and just little directions that I need to go back in and redo it. I have just directions on step-by-step with the screen chart. This was just so much easier.”

The need for memorization and notes is in violation of several of Nielsen’s usability heuristics. The match between ERP systems and the real world is not particularly good, and, clearly, ERP systems require recall rather than supporting interactions based on recognition. In addition, the lack of navigational and procedural guidance violates heuristic #1: system status is typically not available, leaving users unsure of their progress in performing a task.

I’ve seen users create a ton of cheat sheets and I’ve created a ton of cheat sheets for users. While our training and implementation plan leads to a flawless implementation, users simply don’t want to have to wade through pages of job aids to find a quick answer to their problem.

Tell me if this sounds familiar:

User 4: “If I had a new person in purchasing, I’d need to tell them what the company code was and how our GL chart of accounts worked and what our cost-center structure is – a lot more details in order for them to be able to enter just one invoice. And then it’s spider webs off of that as far as whether it’s a fixed asset or pre-paid, etc. So there’s a lot more information that needs to be shared there if we had a new employee in any one of those areas.”

Since the system maintains the business information, it could easily present it to users if it had been designed to do so, right? This example suggests another violation of Nielsen’s heuristics: the match between the system and the real world is not as good as it could be.

Information on progress and feedback to the user are important and the system should provide it when the user needs help. However, the system must first be able to detect and recognize that need for help, but ERP systems typically play a passive role:

User 5: “Now, the thing is that in this case, the system is not reaching out to you saying that you obviously need help. It’s me having to go find it there. Just to go back to that GL account scenario, rather than just telling me you had to put something in, if it knew automatically what that one was supposed to be, and once you failed, say three times, or X times putting in the wrong one and then at that point, it would query you – you obviously need help here. And then it would send you to a help desk function.”

ERP systems often fail to utilize the contextual information they possess regarding the organization, user, business process, and task. An error message may simply report that there is a problem without offering any diagnoses or suggestions, or even isolating where that problem exists. While some error messages provide possible solutions, users often find them to be too general to be helpful:

User 6: “No, it doesn’t tell me detail, but it tells me that it cannot be performed at this time.”

User 2: “It’s just the [dinging] sound, yes! Nothing comes up and you know that you’re looking at the wrong order in the wrong [location]. It doesn’t come up with a pop up screen that says this is the wrong order.”

Some users try to seek solutions by reading system-provided help documents, but this is not a productive use of time, as the documents are often not specific to the task at hand and do not consider the context of the activity. As a result, users typically ask someone else (coworkers, superusers, IT staff ) for help:

User 5: “I would just call someone because again, I have spent time trying to figure it out and go through the menu path, and I feel like I always get more lost and I’m just trying to save time, so I just usually pick up the phone and call someone.”

These examples illustrate violations of Nielsen’s heuristics and in an error situation, the users find it impossible to use the system to identify needed status information, and the system is often unable to help users recover from errors.

Human-Computer Collaboration

A collaboration between two parties will likely fail if they do not maintain good communication. Communication requires sharing knowledge, which, in ERP systems, includes business data, the procedure for a task, status and progress reporting, and context. To communicate and share knowledge, the system should speak the users’ language and use the vocabulary of terms with which they are familiar. However, the terminology used by some ERP systems is drastically different from the users’ and little or no explanation is provided about what terms mean:

User 5: “I don’t know how it’s chosen that for vendors it’s XK, and for purchase orders it’s ME prior to the numbers. I do know, obviously, the numbering system as far as O1 is for creation, O2 is for change, and O3 is for display. But have no idea what it means to the actual function!”

User 7: “Sometimes when I get an error message and I don’t know why I’m getting it then that’s when it’s questionable about what’s going on. Because usually it’s in codes, and I don’t understand that.”

Incomprehensible terms and error messages do not “Speak the user’s language” nor “Contains familiar terms and natural language.”

To maximize the long-term success of a collaboration, each party needs to learn from and adapt to the others. In interactions with ERP systems, users are the ones who must do the adapting. An alternative would be for the system to also adjust to its users’ behaviors by taking into consideration their previous actions. This would enable the system to automatically populate previously entered data, list functions in the order of frequency of use, offer an option of repeating a frequently performed task, etc. However, such capability is currently lacking:

User 7: “I don’t think it does something to make it easier due to the replication of me doing something. So, if the system had enough intelligence that it noticed that I am always printing the details for all the items that are on the overall report, and then it would say let me offer you, do you want to print all of this? You seem to be doing this always.”

The above examples illustrate the lack of collaboration between ERP systems and its users, and the frequent violations of Nielsen’s usability heuristics can be framed in terms of the non-collaborative behavior of these systems. A true collaboration aimed at enhancing usability requires a partnership, the absence of which is best summarized by a superuser in this way:

User 8: “So with the system, it’s somebody that just smirks at you. And when you make mistakes, it looks at your with the same kind of dopey look on its face . . . And it starts forcing you to kind of work around and work over and work under. And that’s the frustrating part about it that again is the biggest pain in the backside. So, I would say, it’s not a good partner, I feel like it’s an impassive sometimes uncooperative coworker.”
What’s Being Done by SAP and Oracle
The long rivalry between SAP and Oracle may finally come to an end and there probably won’t be a winner. As smaller software companies modernize ERP systems, Oracle and SAP and are rushing to catch up. But will it be enough and will the changes get to market on time? Ten years ago, companies essentially had two choices when going ERP: Oracle or SAP. Not anymore.
Today, there is a list of ERP software companies showcasing their offerings and experiencing rapid growth. Some of which include:

Gone are the days of brute force ERP implementations. These upstarts focused on the “pain points” of companies and have created user-friendly interfaces and software that is easy to deploy.
While these upstarts are adding customers every day, it’s encouraging to see Oracle and SAP making efforts to change their applications. Nielson’s heuristics have been out for 20 years. One has to wonder: why are changes just being made now?
Below are some of the new features they plan to incorporate, or have incorporated, in their latest releases.
Visual Processes
Both companies have created visual processes that allow users to easily see how to perform an entire process from end-to-end by providing a graphical map of a particular workflow. Users can see the entire work process at a glance to instantly determine where they are in the process and the steps required to complete it.
Graphical Dashboards
Dashboards provide executives and managers across business units with key performance indicators. Dashboards don’t require users to be familiar with the software and can use these graphs to gain direct access to key information. It also improves collaboration across the business.
Better User Interface
Designers of ERP software are finally paying attention to the needs, wants and limitations of the product’s end users throughout the design process. Not only are designers trying to determine how users will use the product, they also test their assumptions with real users. The goal is to optimize the product around the way the users want and need to use it, rather than forcing users to change they way they work to accommodate the software.
Configurability
Systems that are easily configurable, allowing users to set preferences, enable or disable a feature, or change the user look and feel allows users to work with the system in the way they want to without the need for extensive programming. It also allows users to eliminate extraneous information on application screens to reduce confusion.
Mobile Interface
These days, if you’re application isn’t available on mobile devices, you’re application is dead in the water. If users are out of the office or away from their laptop, they should be able to query information and use application functions to perform tasks such as checking inventory or placing a purchase requisition. This flexibility helps broaden the user base to non-core users and fosters collaboration.

Conclusion

Usability is something that Oracle and SAP are finally focusing on.
But is it too little, too late? With a generation raised on user-friendly apps, websites with sleek user experiences, and software created by Apple and Google entering the workforce, their tolerance for poorly designed software will be close to nil. With the number of customers SAP and Oracle have, transitioning them to upgraded versions of their respective software will take years. It will also cost money for their customers to migrate to these new versions.
Will these upgrades be enough to keep their customer base or will customers make a move to modernized ERP software systems?
Time will tell.
And the clock is ticking.

Secrets of a Successful Software Implementation: Part 4 of 4

By Carlos L. Aguilar 2 Comments

Just Released: a 10 step process to help you with your next software implementation.

Click here to download now

When a company decides to implement new software, a business case is created showing the Return on Investment (ROI) of the project. The leaders of the company agree it is a good idea to proceed with removing the current system and implementing a new system to make the business run faster, more efficient and provide transparency across business units.

Unfortunately, for many of these companies, the rollout won’t go as planned. Money will be wasted, the project will be improperly managed, and upper management may not support the project to the end. The focus will be on the technical side, the software’s capability; its bells and whistles. Preparing the organization with a training and implementation plan will be pushed aside.

The project will fail.

Don’t allow your project to fail.

My goal in writing this four part series is to share the important lessons I learned when I implemented Oracle in numerous countries. Hopefully you have read the first three articles prior to diving into the fourth and final phase of the Training and Implementation Plan. If not, I encourage you to read them. I don’t want you to feel like you are reading the end of a book without first getting to know the plot and its characters.

Whether you’re a CEO, CFO, CIO, Director of IT, Project Manager or simply involved in an enterprise software implementation, use this information to be successful. Don’t allow the project to fail because end-users were neglected and the focus was on the technology of the software.

Even if you’re in the midst of a project, you can still take certain phases of this plan to augment your implementation.

The fourth and final phase in the Training and Implementation Plan is Final User Training and Certification. As the name implies, users will be given a final session of training and then given an exam or assessment. Throughout this article I will use exam and assessment interchangeably.

Why? Over the years of preparing organizations for go-live, I found that people reacted to each word differently. If I mentioned “exam” people sometimes tensed up before taking the exam and didn’t perform well. If I mentioned “assessment” people sometimes didn’t think the word carried as much weight as “exam” and so they would not take the exam seriously. I digress.

Now that we have all four phases identified, let’s see how they look together:

Phase 1: Face to Face Training and User Assessments
Phase 2: Monthly Web Meeting and Mini CRP Sessions
Phase 3: User Proficiency Tasks
Phase 4: Final User Training and Certification

Now this looks like a thorough and well thought out training and implementation plan! Imagine taking this plan to your boss or the CIO and showing them exactly what the plan is for getting the organization ready for a new software implementation. Do you think he or she would be impressed?

Final User Training and Certification

This fourth phase is a culmination of the three prior phases. Its purpose is to certify that users are, in fact, ready to use the system on day one. How does this certification take place? After UAT has been conducted and the users have accepted the current configuration of the system, conduct a certification training session with said users in a test instance.

When should this training occur? It should take place approximately one week before go-live and the length of the training session commensurate with the amount of material that needs to be covered. It will serve as an end-to-end walk through of all the functions users will be performing in the new system.

For example, a user who is responsible for client billing will need end-to-end training on setting up the customer, creating billable and non-billable items, entering quantities, creating invoices, correcting invoices, and closing out the project when all the activity has been completed. It is important to accurately plan the agenda and segregate users by function during this training. Example: purchasing, supply chain, finance, etc. will each have their own sessions.

At the end of this training, the user will take an exam that is created and administered by the core team. The exam will be created using Google Forms (as demonstrated in Phase 3) and is a comprehensive exam that includes both practical and theoretical questions. The length of the exam and types of questions should be representative of what a user would know after using the system for 8-12 months.

If this sounds unreasonable, it’s not. The goal of the Training and Implementation Plan is to transfer as much knowledge from the core team to the user base. Wouldn’t it be nice if all of users were as proficient as the core team? If they were, go-live would be a non-event and no one would be worried about whether the organization is ready, right?

There’s a reason this plan is so comprehensive: implementing company-wide software, especially ERP’s, is not without risk. There are thousands, often millions, of dollars at stake. Not only that, jobs are at stake too. High level executives who made the decision to implement an ERP put their job and reputation on the line. If the implementation is a failure, so too are the executives — as unfortunate as it may be. I’ve seen CIO’s lose their job because of a failed ERP implementation. An average Oracle and SAP implementation will take a minimum of 1 1/2 to 2 years to implement from the time of project kick-off. This is a significant amount of time, money and resources to put on the line when it comes time for go-live.

Regarding the certification exam, the training and exams should be administered on site where the user base is located. If your company is based in the USA but is rolling out the software to a group of users in Belgium, members of the core team will travel to Belgium to deliver the training and administer the exams. The reason for this is obvious: it costs less to send a small team to Belgium than it does to send a large user base to the USA for training. To be certified using the system, users need to achieve a passing rate of 75%. Ensure a member of the core team has taken the test first and correctly answered every question. This first entry in the spreadsheet will be the “answer key”. Once you have an answer key created, you can grade the exams.

Below is a snippet of one certification exam I used during the Oracle rollouts. If you would like to see the full form, click here.

After each person has submitted their responses, sit down with them individually to review the results. If a person failed the exam, work with he or she privately to determine if the reasons were related to not knowing the content or simply nerves when taking an exam. Allow them to retake the exam after speaking with them. Always be encouraging and positive when working with the users during certification.

What if a person simply cannot pass the exam even after multiple tries? This could happen and did happen to me during rollout #1. After we completed the training session, we spoke with this person’s supervisor and advised him of the results. It was decided this person would be retrained privately and retake the exam. She ended up passing this time — barely. After go-live, we sent a member of the core team to her location to support her since we knew that her level of proficiency was low, compared to her peers. Remember how I mentioned in Phase 1 that the level of skill required to operate in systems like Oracle and SAP are often higher than what was required of the legacy system being replaced? That was the case for this person. Despite being retrained and retaking the exam, she could not adequately work in the new system. Her supervisor ended up re-purposing her to another function within the organization that did not require heavy use of Oracle.

Now that all of the users are have been certified, the four-phase plan is complete and there is nothing left to do, right? Well, not exactly. While the user base is 100% ready to go, there are still some important tasks that need to be completed before “hitting the switch”. I would be remiss if I neglected to mention that a good cutover strategy is needed to ensure the success of a software implementation.

What is a Cutover?

So what exactly is a “cutover”? Simply stated it is a move from one defined state to another. With regard to software implementations, it is the move from one system to another — for example: from a legacy system to SAP. A cutover plan is designed to minimize the ongoing risk of moving from one system to another. It is the process of identifying key activities that need to be performed prior to moving to the new system. Some examples of these activities are: loading inventory items into the new system or creating and setting up projects in the new system prior to go-live. It also includes the task of migrating code from a development or test instance to the production instance.

Once these activities have been identified, they become tasks that are assigned to key stakeholders of the project. These stakeholders can be anyone from a project lead to a controller who has to ensure the books are reconciled prior to moving to the new system. When developing a cutover plan, you will want to identify key activities well in advance so that the core team and stakeholders can agree on the tasks and be aware of when they need to be completed.

It’s a good idea to lay out this plan in both task format and calendar format. In the task format, list the following items with each activity needing to be performed:

Task name
Start Date
Finish Date
System (legacy or new)
Resource (group or person)

Everyone needs to have a copy of this task list. Ensure there is oversight and follow up to make sure the tasks are getting completed by the finish date.

While adequate planning is the best form of preparation, there also needs to be a section in the cutover plan where a critical decision is made by a key stakeholder: move forward with the new system or rollback to the legacy system. Go or no go. This means that you need to have decision checkpoints along the way during the cutover process. For example, a piece of code that was migrated to production is not working and is requiring a significant amount of troubleshooting. Do you hold off on go-live until this code is functioning or do you press forward with go-live and create a temporary work-around to this process? These types of issues need to be considered in your cutover plan.

Another key part of the cutover plan is the ramping down of business in the legacy system prior to transitioning to the new system. Projects need to be closed out, payments need to be applied to A/R balances, and items need to be received against open PO’s. There are a number of things that need to occur as part of the ramping down process. A good illustration of this was created by Mahesh Vallampati, a Practice Principal at Keste:

The graph is fairly self-explanatory but as you can see, business ramps up prior to go-live. This is due to all of the cutover activities that need to be completed (like those open PO’s I mentioned above). You can also see that productivity in the business is dropping just before go-live. This is because cutover activities have been completed and the user base is ready to use the new system. Once go-live has occurred, there is a controlled business ramp up in the new system. People become comfortable with the system and the project teams roll out parts of the system in small phases. After a period of time, business volume returns to normal and all is well within the company.

There’s also a cutover perspective from those in IT and those who are part of the core project team. Both of these groups have a set of cutover activities that need to be completed prior to go-live. This could include the migration of code, completing setups within the new system or bringing new servers online. Here’s another graphical representation from my friend Mahesh:

The activities for this group also increase prior to go-live as they are in the trenches executing the well thought out cutover plan and wrapping up last minute configurations of the system. They are utilized immediately after go-live to support business ramp-up. As activities in the new system increase and business returns to normal, the IT team moves to a steady state support of the business. As you can see with line Y-Z, there was always a steady state support of the business from IT via the ubiquitous Service Desk.

This is the cutover plan from both the business perspective and an IT/core team perspective. These charts provide a useful illustration as to what is going on within a company leading up to go-live. Feel free to use these charts to communicate to your users and stakeholders — it helps put everyone on the same page leading up to the event.

Managing Change

As with the need to mention a cutover strategy, it is also prudent that I mention another important component to implementing software and that is change management. There is a large amount of information out there on the web with regard to change management. Over 92,000 titles on amazon, in fact. Yes, 92,000. Have a look:

You might have a favorite book or theory regarding change management and I’m not here to challenge it. Therefore, I am not going to devote a lot of time on the subject. However, I do believe change management is a critical success factor for any major company project; especially for enterprise software projects.

Due to the scope of the Oracle rollouts, it was important for us to identify where everyone was on the “change curve”. The company was divided into four regions: North America, Asia Pacific, Latin America, and EMEA (Europe Middle East and Africa) and there were three planned rollouts. Latin America and EMEA were combined during the third rollout. These regions contained the end-users, the organization, a.k.a the money makers. It was these individuals who received our attention and were the most important to the success of our project.

In addition to the regions, there were company executives and members of the core team who were involved in the decision making process from the beginning. Let’s have a look at the chart below to see where people were at different phases of the project.

The project kicked off 2010 and as you can see, the executives and core team were at the height of the change curve with “Informed Pessimism” which turned to “Hopeful Realism” and “Informed Optimism” as we neared our first rollout which was in North America (Note: go-lives dates indicated by the apex of the curves). This was because they were kept informed about the progress of the project and whether or not we would be ready for the first go-live. Notice how that green line representing the executives ticks upward during the next two launches but by the third rollout their focus returned to the daily issues of running the business. By the third rollout, we predicted the executives would be returning to running the company after being successful with the first two launches.

You’ll also note how the regions reacted to each go-live. Latin America and EMEA didn’t even register a pulse for the first rollout in North America because they were still a year away. Asia Pacific showed some “Informed Pessimism” during the first launch and after we completed the North America implementation.

Our team shared this chart every opportunity we could with both the executives and the users throughout the implementation. It provided individuals with information about what to expect during the milestones of the project. With this information and the Training and Implementation Plan, it helped foster change within the organization.

On-Site Support

The final piece to a successful software implementation is providing on-site support at key locations within the organization. It’s important that a member of the core team is sent to locations where there is a large user base or a location that generates a lot of revenue/transactions. While there will be Subject Matter Expert (SME) on site, it’s still wise to put a member of the core team on site to assist with any issues that may arise. If you can, put someone at each location.

Psst! Let me tell you a secret: there will be issues at go-live. No matter how much testing or planning is done, inevitably something goes wrong in the system. Especially if it’s a large scale ERP like Oracle or SAP. I’m not referring to “show-stoppers” that halt the project altogether. I’m talking about bugs in the system. You may have to create temporary work-arounds until the bug is fixed.

Having a member of the core team on-site at go-live gives a significant morale boost to end-users. Even though you have thoroughly prepared people for the big day, there is going to be anxiety about what will happen on Day One. I cannot tell you how many times I was thanked for being on-site during the big launch and how it alleviated tension within the office.

In addition to providing on-site support during go-live, I highly recommend having a core member of the project on-site during the first month-end close. As there will be anxiety about go-live, the same can be said for the first closing of the books. Ensure there is someone on site a couple of days before the last business day of the month and have them stay at least a week after to support month-end.

Conclusion

Phase 4 of the Training and Implementation Plan is Final User Training and Certification. Final User Training and Certification should take place about a week prior to go-live to ensure information and knowledge remains fresh for the trainee. Users are allowed to retake the test as long they understand the reason they missed the questions. There is a fine balance between someone failing and then getting the answers from the core team and subsequently passing the exam versus someone who really doesn’t know the answers to the questions.

While the Training and Implementation Plan will successfully prepare the organization for go-live, it’s still necessary to have a good cutover plan to ensure all activities and transactions are completed in the legacy system prior to switching over to the new system. Be sure to create critical checkpoints during the cutover as part of the “go/no-go” decision strategy. Just because you have to rollback to the legacy system for a period of time does not mean your implementation is a failure — it means you are wise. However, continuing on with the implementation when there is a non-functioning essential feature will result in a failure unless it can be fixed quickly.

Be aware of where people are on the change curve. Communicate to them where they are now and where they can expect to be at various phases during the rollout. Use the chart I provided as template for your project.

On-site support at go-live and month-end is a success factor and will boost morale with the user base.

By now you should realize that large scale software projects involve risk, money, time and resources. ERP software is complicated. It’s bulky, rigid, unforgiving and requires custom code. When businesses choose to implement a new ERP, it has a tremendous impact on the organization.

Research has shown that a user training curriculum is always the most underestimated budget item in an ERP implementation and will typically cost 10-20% of the overall budget. It will also involve 10-20% of the personnel within the organization. Therefore:

TRAINING IS IMPORTANT

Don’t ignore the need to train personnel. It’s easy to get caught up in all the cool things the software can do but it can’t replace your workforce — no matter how hard you try. And your technical consultants aren’t the right people to train the organization. Hire the right person or firm to do the training and preparation of your people.

Don’t let your software project, be it ERP, CRM or otherwise, show up as a statistic in the “failure” category and become a Harvard case study. Instead, use this Training and Implementation Plan to be a success and let Harvard do a case study on how to successfully implement enterprise software.

Too many documented failures already exist.