When I was a little girl I loved ballet, and I enjoyed every second of those 14 years. As I grew up I started to love writing. My favorite class was Creative Writing, and I’ll never forget how Miss Robin encouraged us to embrace our ideas and thoughts, always starting with a brainstorm.
I remember loving writing essays in high school. I helped everyone and because I loved writing them so much, I was good at it. My passion towards writing was reflected in every paper I delivered.
My passion for words and content drove me through my University years and it’s no wonder that I am proud to be part of the Epicor University department for a few years now. I love my job and I enjoy every part of it.
As technical writers, we have the opportunity to reach thousands of eyes, and during the journey, we learn priceless things, we meet new people, we work in teams, we discover new things, we find a thousand ways to explain one idea, and we have the chance to understand our customer’s needs, and do everything to deliver high quality work.
Every project is different, every application has specific needs, and every team performs different tasks. All the pieces come together in the end and the passion that each participant puts in their work makes a difference in the final outcome.
The way we work as a team is crucial. We work as a team among the writers, and we also work with different departments: Development, Support, Quality Assurance, Engineering, Sales, and Training. We are all pieces of the big puzzle.
I’ve been asked a few times if what we do isn’t “too boring” or “too monotonous“ and my immediate answer is always the same: “Absolutely not, I love it”. We are part of a huge company with big projects and the best applications. As a technical writer I always have new projects, different tasks, numerous teams I work with, and many people that help me along the way. Our job is far from being seated and writing non-stop. We create content, we learn, understand, and explain. We help people to easily understand and use a product, our words and work reach eyes that we will never imagine, and there is no greater feeling!
Posted by Victoria Garza, University Content Specialist
In my first attempt at this, my first blog post, I immediately lost sight of the objective – keeping it simple…
Most of what I have learned about instructional design over the years I can sum in a few words: keep it simple. In concept, this might seem straightforward, but in fact, the road to effective instruction, regardless of the delivery method, can be anything but simple.
I found that in order to make my instruction effective, I have to build it on a solid foundation. This includes determining the end task, or tasks, or knowledge that the job requires of the learner, writing clear and instructionally measurable learning objectives to meet those requirements, limiting instructional content to that which is required to meet the learning objectives, and providing means for the learner to demonstrate their knowledge and/or skill acquisition. It also helps when I can make the training engaging.
When I started developing training, I was doing so for topics in which I had a good deal of expertise and I was easily derailed into writing content that was nice-to-know, but did not really support the learning objectives, which inevitably seemed to be crafted to meet the content. Now, I start with a solid learning objective and I make sure that everything I put into my training content either directly supports the learning objective, or is foundational knowledge or skill that is required to support the content that in turn meets the learning objective.
In short, one of the most important things that I learned about instructional design was to write specific and measurable learning objectives. I avoid vague language in my objectives such as “know” or “understand”, replacing them with direct language such as “state”, “describe” or “demonstrate”. By using direct, measurable language, I know exactly what to include for training content, and the learner knows exactly what to expect in the training.
Keeping it simple, one objective at a time…
Posted by Robert England, Content Specialist, Epicor University
Earlier this year, I began transitioning from writing content for Epicor HCM to Prophet 21 application. The more I read up on Prophet 21, the more I realized it was a very different application than what I was used to. So, I treated it like I would any other writing project—I asked questions, built on my existing knowledge, clarified expectations, began my first project, asked more questions, and so on.
Anytime I start a new writing project, I’m reminded of the writing process taught in school: planning/pre-writing, drafting, revising, editing, and publishing. While we often think of this as a method of teaching students to write, the truth of the matter is, whether starting a new project or being brought into an existing project, writing for software isn’t much different.
Planning – When starting any new project the first step is building a strong foundation. Develop relationships with the people already involved with the product, establish lines of communication, and use the existing resources, including the training courses, documentation, and people, to learn all that you can about the project and subject matter.
Once you have that foundation, identify any standards and styles already in place before building the content. This may require additional research – review style guides and ask questions of the subject matter experts.
With software, planning also includes going through the steps and processes within the system, determining how they all work together, and then deciding which type of document best meets the needs of the audience. Consider creating an outline to ensure that all bases are covered.
Drafting – Drafting begins when you take all of your preparation and planning and begin writing the content. As you write, there is a good chance that you’ll need to go back and do additional research – ask more questions of the subject matter experts, and write as you rework your way through the steps and software processes.
Revising – Review your content, pay close attention to the style and structure. Test any instructional steps in the document. Then make any changes as needed, such as adding additional information, rearranging steps and information, and removing or replacing any content that doesn’t work.
Editing – Proofread your documentation for grammar, then ask subject matter experts to complete a review of both the content and the overall cohesiveness of your document. Once everything is said and done, you likely need to make a few changes, apply a handful of final quick edits, and do a bit of cleanup.
Publish – The final step for writing for software is getting you documentation into the hands of your end users. Depending on the document type, this might be publishing online help to the software system or uploading supporting documents to your company or product website.
Starting a new writing project can sometimes be intimidating. But by breaking your project out into the five basic steps of the writing process, it doesn’t have to be.
Posted By Christine Stretton, Content Specialist, Epicor University
When I was asked to write this blog post, I was a little nervous. I have never written a blog post before, much less one that can be read by the entire world. I felt ill at ease and unsure at doing something different. As I was calming my nerves in preparation for this new challenge, I started thinking about comfort zones and why it’s important to stick a toe outside them.
Sometimes in work, as in life, it can be difficult to break out of our patterns, the things we do on a regular basis with comfort and expertise. It can be frightening to try something new, to take a risk, especially in the workplace. What if we fail? That fear of failure can lead to unwillingness to expand past our comfort zone to being stuck in a rut where we don’t grow or develop to our full potential.
As daunting as it can sometimes feel to try to perform an unfamiliar task, there are advantages to moving past our discomfort and staying open towards new opportunities. Here are some benefits to stretching out of our comfort zone.
Challenging ourselves – When we only do what we already know how to do, our work can become stale and repetitive and this can lead to feelings of boredom and dissatisfaction. We end up doing just enough when we are capable of doing more. When we challenge ourselves to achieve new goals and those goals are achieved, it communicates that we are the type of employees who want interesting, challenging work to perform. We open ourselves up to opportunities for further achievement and satisfaction in our careers.
Growing and Learning – In life, we should always be growing and learning new things. Stretching to learn unfamiliar skills keeps our mind sharp and allows us to develop as people. Even when we don’t immediately achieve our goals, we can learn something important in the effort itself. We learn how to cope with and learn from our mistakes. Innovation comes from not only knowing what does work but from learning what doesn’t. A skilled and knowledgeable employee who is able to innovate is a valuable asset to our company. The more we adapt, learn and develop our skills, the more valuable we can become.
Gaining Confidence – We all experience insecurities and self-doubts when trying something new. That first tiny step outside of our comfort zone can feel as if we are climbing a mountain. When we do take that first step and the world doesn’t crash down all around us, it makes that second step a little less frightening. A few more steps and we find ourselves walking easily along the path to new challenges and rewarding experiences. The more we face our fears, the less power we give them. The more we prove to ourselves that we can overcome obstacles, the more we start to feel confidence in what we are capable of achieving, both in and out of the workplace.
Remaining nimble – The ERP environment is one marked by high demand and rapid change. We must be able to be nimble in that environment, to adapt and respond successfully to the needs of our business and our customers. Change is coming whether we like it or not. Instead of resisting or dreading it, we can choose to embrace those changes and make them work for us. Epicor University has taken advantage of changes in education technology to develop an extensive portfolio of different learning options that encourages lifelong learning for both our employees and our customers.
Expanding our comfort zones – A surprising thing happens when we stretch outside our comfort zone; our comfort zone stretches too. The challenges that once seemed impossible for us to achieve now become part of our skill set. As we continue our growth and development, we become more comfortable in trying new things until the act of challenging ourselves becomes part of our comfort zone. By going out of my comfort zone and writing this blog post, I’ve learned that I can write a blog post. As a result, I’ve become more comfortable with stretching my writing skills into other new directions.
To conclude, when we work through our anxiety and challenge ourselves in the workplace, we have a greater opportunity to grow personally and professionally. This can result in a more positive attitude towards change and a confidence that we can stretch beyond our comfort zone to take advantages of the wealth of opportunities just beyond it.
Posted by Tricia Symes, Sr University Specialist, Epicor University
Safety Supply Illinois (SSI) is a distributor of safety products ranging from earplugs to high-end safety equipment, including fall protection and confined space solutions. SSI converted to the Epicor Prophet 21 enterprise resource planning (ERP) solution in 2012.
According to SSI Owner/Chief Operating Officer Mary Porter, “The online learning classes from Epicor University were extremely helpful in introducing the new functional aspects of Prophet 21 to our employees. The online training schedule provided by Epicor’s Learning Management System (LMS) allowed me to create, schedule, and track user-specific training timelines.
“The LMS is wonderful for training new users on Prophet 21, and because it is organized by business function, I encourage our existing employees to listen to other classes and learn about all functional areas,” continues Porter. “We are slowly incorporating many of the Prophet 21 enhancements into our business practices with help from the Epicor Learning Center.”
The results speak for themselves. Porter observes, “In the last three years, we have tripled sales, in part because we converted to Prophet 21. In addition to increasing our overall customer base by about 20 percent, we are also attracting much larger customers such as utility companies. The Epicor technology and tools for learning and growing are all there; you just need to access them.” To read the full story of SSI’s success, go here
Posted by Epicor Social Media Team
Did you stay up later then you intended to last night? If you did, chances are you were sucked into a great movie or a favorite book. That’s what a good story does . . . it grabs our attention and holds it until a creative or surprising resolution gives us satisfaction and contentment. But stories do much more than entertain . . . a good story can help us learn and make it easier for us to remember something long after we see it on screen or read it on a page.
A simple example of this is a fourth grade spelling teacher showing the class a trick to spell “rhythm” by remembering the one-line story “Robin Hood Yelled To His Men!” Did you picture Robin Hood in full costume running around Sherwood Forest calling for his band of merry men? I always do. Stories make things easier to recall because they put our whole brains to work, imagining pictures and movement, sounds and smells. Stories power memory.
On a completely different level, think about the history student slogging through dates, data, and textbook explanations about the politics of World War II. Introduce that same student to Anne Frank’s diary and watch as the power of the story taps into his heart, transporting him from the school library to a secret annex in war-torn Europe. Stories make people care and arouse interest.
As difficult as it can be to apply stories to the world of ERP software documentation, top-notch documentation writers and classroom trainers often use examples and real-life stories to capture attention and engage with their students. The following are some examples of how stories can help people understand a difficult concept or remember something useful.
- Several weeks ago I attended a training to learn how to use Epicor software to schedule production jobs on a shop floor. There were many terms in the process that I didn’t comprehend right away and I had trouble discerning between them. The trainer who was leading the class used a story involving a burger joint drive-thru to help me remember how the process worked. For each step in the unfamiliar, she gave me a corresponding step that I understood: waiting in line, ordering, the burger being cooked and put together to my specifications, then lunch bagged and moved to the cashier. Stories reshape information into something meaningful. When embedded in the context of a story, it is transferred to the listener or reader in a unique way.
- When correcting a piece of documentation regarding on-time transaction approvals, I read the material and found myself hopelessly lost (noticing a theme here?). I scheduled a demonstration with a subject matter expert, who used various scenarios to help me understand the many ways that time transactions can be tracked and approved. Through the adventures of Peter Project Manager, Sally Supervisor, and Emilio Employee, I learned different ways to configure settings and how to obtain the desired results. Ultimately, I was able to pass the information along to end users by writing examples like his – what worked for me I knew would work for others. People take time for stories. If you want to maintain an audience’s attention through something tedious, you’re more likely to do it through storytelling.
- When developing a basic training video to teach users how material flows in an out of a distributor’s warehouse, a coworker created an effective piece using a story about a safety helmet. In the story, a customer came shopping for the helmet, went through the sales process, and an order was placed. The helmet was not on hand and had to be purchased, received, and then shipped to the customer. In following the ordered material through the process, the learner could take in the information the developer wanted to convey – how material moves from start to finish – and also learn terminology through the simple example. Explanations, especially of complex processes, benefit from having a beginning, a middle, and an ending.
In closing – those of us who are tasked with taking the complex (or the tedious, or the completely confusing) and interpreting it for others need to use every weapon in our arsenal to do our jobs. Storytelling is effective. And – even in the context of software documentation – it is, occasionally, rather fun.
By Deb Amato, Sr. Content Writer
A few posts back, Dawn wrote about writing technical documentation in a Scrum environment. She provided an excellent overview of what Scrum is and how to navigate it as a writer, so I won’t retread her ground here. Instead, I would like to address an aspect of Scrum development that seems unique to writers: serving on multiple teams at once.
Ideally, the way Scrum works is that everyone on a team is a 100% dedicated resource. While developers and QA analysts might have some other small tasks to do while working in Scrum, their primary focus is the team. However, a technical writer might be split between two or more teams, sometimes as many as four or five. When that happens, keep the following in mind.
1. Let it be Known
Your Scrum master has an expectation that all the people on his team are there to work on his team 90% or more of the time until the close of the last sprint. If you’re on multiple teams, you can’t do that. Let your Scrum master know this at the team kickoff. It’s important he knows this.
2. Pick Your Meetings
Scrum is a meeting-intensive development method. Scrum prioritizes its backlog into “must haves” and “nice to haves.” In a pinch, you can apply the same to meetings. Every team has the following meetings:
- Daily Standup – 15 minutes in which everyone says what they did yesterday and what they plan to do today.
- Story pointing – 2-4 hours in which the product owner explains the stories (features) that the team will be addressing, and after a brief discussion the team assesses its work effort. Occurs at the beginning of the sprint, and pops up again when non-assessed stories are considered later in the process.
- Sprint Planning – 1-2 hours in which the team determines which stories they will address in the coming sprint. Occurs every two weeks at the beginning of a sprint.
- Retrospective – 30 -60 minutes in which the team goes over what went right and what went wrong and how processes can be shored up to make the team better. Occurs every two weeks at the end of a sprint.
- Demo – 30-60 minutes in which the team presents the work it completed in the last sprint to stakeholders. There is often an internal demo first, followed by one for customers.
That’s quite a list, but it’s manageable, and a lot of these only happen bi-weekly, so it’s a little hiccup in the work schedule and then back to it. . . until you double it, or triple it, or more. At that point you will spend all of your time in meetings and none of your time actually writing anything. If you’re going to have any time to work, you may have to skip some meetings. But which ones?
Story pointing meetings are a must. Of all the meetings, this is close to the top of importance. Remember, Scrum uses no specs. Since everyone (except you) is only working on this team’s work and in constant contact with one another, there is little written material for these features. That’s what you’re there for. So, the best way to get a handle on what the features are and what they do is in the story-pointing meetings.
The other essential component as far as meetings go, is the standup. I’ll admit that I work through most of mine; when developers start talking about the particulars of code they’re not having a discussion I need to be a part of. However, by being present at the standups you establish yourself as a member of the team. This is vital for building your relationship with everyone else and putting the idea in everyone’s mind that yes, there is a writer here, and yes, we need to tell him when we change something. And things will change; that’s why it’s called agile.
As for the rest of the meetings, it’s always better to go if you can, but you’ve got documentation to produce, and that takes time too. You have a responsibility to your teams to complete the doc tasks for each story. Sometimes that means you can’t attend every meeting. This is part of the discussion to have with your Scrum master when you explain you’re not an exclusive asset.
3. Focus and Float
Did you know that every time you receive an email it costs you 3 seconds? That’s assuming you don’t open and read it. From the time you see the notification that you have new mail, it takes 3 seconds to reorient your brain back to the task at hand.
The moral of this story is that to be truly effective, you need to focus and shut other things out. No, I’m not telling you to kill your IM channel and close Outlook. But I am suggesting to you that doing one story for one team and then one story for another is slower than taking a chunk of related stories for one team and working on only them for the day, or even the week, and leaving the other teams’ tasks for another time.
Yes, this means that you’ll be going to most your standups and saying: “I have nothing to report today.” That’s fine. Do that.
Understand this might also mean that a sprint may close without your doc tasks complete. How the team handles this logistically depends on the Scrum master. Most of the ones I’ve worked with will pull those stories into the next sprint with a “doc only” tag on it, meaning everything else is done.
Scrum purists might be gnashing their teeth at this, but if you’re willing to give it this little bit of flexibility and break from the ideal of the process (because really, if this were implemented ideally, you wouldn’t be on more than one team), I can promise you this works. While all of my teams regularly carry doc only stories from sprint to sprint, I also always finish ahead of development before the final sprint.
4. Educate Your Scrum Master
When I first started writing for Scrum teams, the Scrum masters would create the same array for each story: a programming task, a QA task, and a doc task. However, not all stories require a doc task. Speak up in the sprint planning meetings and let everyone know what does and doesn’t have to receive documentation so that your workload is accurately reflected in your team’s tracking tool. If you have to miss a sprint planning meeting and you find a story with a doc task that isn’t needed, bring it up with your Scrum master and explain why. Eventually they’ll learn, or at least default to the behavior of asking you first.
Serving on multiple Scrum teams takes some juggling, but it’s certainly manageable. In fact, I’ve come to prefer serving on two at the same time. However, when doing this it’s important to understand that you’re not in the same position as the rest of your teammates, and so you need a different set of rules to be effective.
Posted by Cliff Horowitz, Prophet 21 Content Team Lead, Epicor University
Epicor University is starting customer focus groups on content. Meetings will be held every other month in a conference call/shared desktop format. Proposed topics will include:
- Tours and functionality demonstrations of newly-released content.
- Sharing of prototypes of content in development.
- Discussions of desired features.
- Strategies for aligning shipping content to your organization’s needs.
We hope that by increasing communication on content and training challenges we all face, we at Epicor University can create better content and improved content vehicles. We strive to deliver content in the way you want to consume it. We would love to find out:
- How do you train new Epicor users?
- How does Epicor training fit in with other systems/process training?
- What are the content areas most consulted in regards to Epicor?
- If you were to design your organization’s ultimate “user guide” to systems and processing related to Epicor, what would it look like? HTML? Videos? Diagrams? Clickable diagrams? Combinations of all those items?
If these topics sound like areas of discussion you would like to pursue, please send us an email at email@example.com, and ask to be included in one of our Epicor University Customer Focus Groups (CFGs). We have several groups, so also include which Epicor products you are using so that we may invite you to the appropriate group.
Posted by Charles Lloyd, WW Director Epicor University
Yes, you can be a content writer in an Agile development environment! In fact, the benefits far outweigh the initial transition pains.
Anyone who's been in the software industry for more than five years can attest that development processes come and go. I think the Agile, Scrum process can be the most beneficial to all teams. Over the years, I’ve created content for software through a variety of request tools or processes: waterfall, cascade, specification sheets, service requests, and my favorite documentation-by-discovery. (This is the “oh, look they’ve added something new” process.)
Content writers have a larger responsibility than just putting words to paper. The nature of our work allows us to be the first user to come in contact with an interface. We are the voice of consistency across an application. We keep non-words from being published on screen – most of the time. We are the first testers and can discover when something is not happening logically. On a Scrum team, involving us in design meetings saves programming and QA rework later.
This is not to say that we do not need to ‘catch up’ occasionally because the number of features being programmed is large. However, being involved up front gives us an edge when the work is ready. There is no blind-siding and because we have been in on the ground level, we might even get a jump on the overview content.
I have read many forum discussions saying that Agile just doesn’t work for writers. We still end up at the end. I disagree. There are certainly growing pains. You must have buy-in from all team members that you are all working together toward the same goal: to create the best end-product for your users. You have to realize your worth and ensure that the rest of team understands the value you bring to the process. You must enlist the support of your Scrum master and not be willing to let poor process slide by other team members. Our end content is what support and customers use first to understand new features (or old features for that matter), it’s vital to get the information you need to make that content complete. You have tools, such as Version1, at your disposal. Let those types of tools work for you. If you’re truly stuck on a new feature and you’re waiting for lynch pin type information, move your task to Impeded. Not to make a statement, but because you’re a part of the team, too! This means that you have to be agile, too. Product owners, programmers, and QA are all involved alongside you and there can be changes that happen after you’ve finished documenting something. Be flexible enough to know that happens and you can update content when needed. It’s all part of being on the team.
Recently, a programmer asked our Scrum master if she should finish the documentation notification form (something we implemented recently) before she moved on to the show-stopper issue that arose that morning. The Scrum master immediately replied, “Get Dawn what she needs first.” (Yes, secretly, I nearly did a jig.) The reality is that the team recognized getting me the information was important and needed to be done before moving on.
I do not want to imply that my job is any more important than anyone else’s. We are equal. We’re a team. My job is as important as another’s. You can write content in an Agile environment…and you can contribute in many, important ways. Take ownership of that value and make it work for the good of the entire product.
Posted by Dawn Miller, Sr. Content Writer, Epicor
Over the past decade we have seen how ERP education has gone from being a purely technical exercise to being recognized as a key component in the overall success of a software implementation. Despite efforts however, we still see how insufficient end user education is often quoted as a top reason why software fails to deliver on its expectations.
In order to make sure that your organization doesn’t fall into the same trap, here are five top tips for how to plan successful ERP education.
- Invest in education. Organizations need to make a solid investment in ERP education for their staff. With a well-planned budget and initiatives, education can help improve user adoption rates, knowledge retention, and software use. Along with these benefits, investing in education reduces users’ errors and rework, user frustration, and on-going support and help desk requests. Companies should leverage their vendor’s education deliverables as they know the applications and can save time and allow resources to focus on their roles within the company.
- Develop education programs. There is no single solution. Even with the hype of technology-based education such as support for learning on tablets, video casts, podcasts, and more, there is still a strong requirement for formal education. It is important to balance the use of new technologies with solid content rather than simply adding technology to the experience. For example, define the learning objectives and integrate formal learning of instructor-led training with informal learning such as a podcast and a job aid. Remember to train all users – from management, project team members and leads, to shop floor personnel – don’t forget any audiences. Also, remember that learning is continuous and does not end with the implementation and “go live”. New employees, organizational changes (processes and people) and system upgrades continue.
- Remember that infrastructure is key. Without a solid infrastructure to support education, there will be limited effectiveness in the development and deployment of the learning. This includes the library/repository of content, the development/authoring tools, the learning management system (LMS), the collaboration and social platforms, and of course, the project management that brings everything together.
- Single sourcing authoring. Effective content and learning requires the advantage of achieving single sourcing of content. The vast majority of companies today jump into content development without developing a single source content development plan. The ability to author in a single tool and store source in a single format (usually xml) pays dividends in translation costs, in flexibility in meeting demands for new output types, in the ability to use a central repository for your global workforce, and in the reuse of content between deliverables. Companies achieve far greater results with single sourcing – from quality to consistency in deliverables.
- Culture of change. Organizations must embrace collaboration, ensure that people know their roles, and assign people with the right skills for their role across the company. The goal is to embrace the change needed to increase performance results across your organization. The performance results are achieved within companies that implement and support effective education strategies.
To succeed, education must be more than a ‘check the box’ effort. Education needs to be effective and to be effective it needs to inform and align users on the why, what and how the software is going to impact them, processes and operations; utilize a blended learning approach; support formal and informal learning; and be continuous, ever changing to meet the on-going user and organization needs.
Posted by Louise Keppel, Vice President, Epicor University