Training Course Case Study - Business Writing for Siemens

One training course that we are seeing high interest in is that of effective Business Writing.  Pentland training recently delivered a one day Business Writing training course for Siemens. 

Pentland Training  worked with Andrea Case at Siemens to deliver a training course that would help her to  improve her Business Writing skills along with three of her colleagues. Jamie Squires of Pentland Training caught up with Andrea after the course to review the training’s effectiveness. Here is the conversation:

Jamie: What lead you to look for a training course in Business Writing?

Andrea: In my new role I am writing Business Cases and Reports as well as the usual day to day emails.  My Manager and I recognised that a training course would assist me to aid my written communication.

How did you find the training course?

The day was great, I learned so much through the practical exercises and the tutor guidance and expert knowledge. I liked the self-assessment we had to do at the beginning of the course, where we each had to pick three areas we would like to focus on. This meant that the training was tailored to the whole group. The tutor continued to tailor the course throughout the day, so we covered as much relevant content as possible.

And your colleagues?

A couple of my colleagues had more experience than myself in Business Writing so they were unsure if they would learn anything new from a training course. They were pleasantly surprised by how much they learned, including Structure and Planning , along with a better grasp of clinical communication. 

Did the training course achieve its objective?

Yes definitely I have put what I have learned straight into practice. I’m much more confident  in my approach to business writing through all the different ways that I communicate. Business Writing is something I recognise that I continually have to work on to improve. The Reference Book that came with the training course will be handy to keep dipping in to. Eventually I will be saving my Manager a lot of time as he won’t have to amend any of my reports!

What would your advice be to anyone looking to improve their Business writing skills (apart from booking an on-site course with Pentland Training!)

We’ll, I don’t think that I’ll forget the ABC rule from the training course. Be Accurate, Brief, and Clear!

Tutor Spotlight - Jane Emptage

Jane Emptage in the hot seat...

How long have you been a trainer for?

I have been involved in training for over 25 years.  This has included IT, Project Management and personal development & management courses.  Hang on, that’s just made me realise that this means when I started training we were using DOS and Floppy Drives!

What’s the biggest change that’s happened in the training world in that time?

The Internet and Computer Based Training . It has transformed so many areas of the training environment and is used by some companies as a ‘total solution’ for all their training needs.  However I still strongly believe that there is no replacement for ‘hands-on’ training delivered by an individual who can bring the experience and understanding to each course that makes it unique.

If you weren't a trainer - what would you be?

A project manager!  That way I would still enjoy the personal satisfaction of solving problems and delivering a solution that I gain from training. 

What is your favourite course to teach and why? 

That’s a tricky one! Probably Communication Skills as it enables me to get ‘up close and personal’ with the delegates.  I really enjoy helping people overcome the barriers they have when dealing with others.  If you have effective communication skills everything you do is so much easier. 

List of Qualifications :-....

PRINCE2 Approved Trainer 

PRINCE2 Practitioner 

Senior Associate Institute IT Trainers

I.I.T.T. TAP 2002

MSC in COBOL

MYEC (in final year BA (Hons) Business)

Quick Fire...

Linked In or Facebook – Personally I’m not a big fan of either, I’m still more interested in talking directly to my friends and business contacts.

Favourite book – All Terry Pratchett’s books, or a good detective story

Favourite holiday destination – I love France , especially the food and wine

Favourite Website – Bing, my favourite doorway to endless information

Favourite personal development tool – The internet of course….:)

10 Rules for Successful Requirements Gathering

To be successful at requirements gathering and to give your project an increased likelihood of success, we suggest following these simple rules:

1. Don't assume you know what the customer wants - ask.
2. Involve the users from the start – they are generally the ones with the most relevant and valuable opinions.
3. Define and agree the scope of the project up-front, it makes it far easier when it comes to tracking and measuring success at a later date.
4. Ensure requirements are specific, realistic and measurable.
5. Gain clarity if there is any doubt – a tight brief makes for an easier project.
6. Create a clear, concise and thorough requirements document and share it with the customer, ideally gaining sign-off early on.
7. Confirm your understanding of the requirements with the customer (play them back).
8. Avoid talking technology or solutions until the requirements are fully understood.
9. Get the requirements agreed with the stakeholders before the project starts.
10. Create a prototype if necessary to confirm or refine the customers' requirements.

Remember, requirements gathering is about creating a clear, concise and agreed set of customer requirements that allow you to provide exactly what they are looking for.  Bear this in mind throughout the project and you won’t go far wrong.

Gathering the Requirements

Requirements gathering is an essential part of any project and project management. Understanding fully what a project will deliver is critical to its success. This may sound like common sense, but surprisingly it's an area that is often given far too little attention.

Many projects start with the barest headline list of requirements, only to find later the customers' needs have not been properly understood.

One-way to avoid this problem is by producing a statement of requirements. This document is a guide to the main requirements of the project. It provides:-

• A succinct requirement specification for management purposes.
• A statement of key objectives - a "cardinal points" specification.
• A description of the environment in which the system will work.
• Background information and references to other relevant material.
• Information on major design constraints.

The contents of the statement of requirements should be stable or change relatively slowly.

Once you have created your statement of requirements, ensure the customer and all other stakeholders sign-up to it and understand that this and only this will be delivered.

Finally, ensure you have cross-referenced the requirements in the statement of requirements with those in the project definition report to ensure there is no mismatch.

Common Mistakes

There are several common mistakes that can occur when gathering requirements.  Keep an eye out for these and try and avoid them at all costs :-

• Basing a solution on complex or cutting edge technology and then discovering that it cannot easily be rolled out to the 'real world'.
• Not prioritising the User Requirements, for example 'must have', 'should have', 'could have' and 'would have,' known as the MoSCoW principle.
• Not enough consultation with real users and practitioners.
• Solving the 'problem' before you know what it is.
• Lacking a clear understanding and making assumptions rather than asking.

Our Trainer thoughts on Requirements

We interviewed Pentland Lead Requirements Engineering trainer on the subject. Here's what we learned from David Orme who has plenty to say on the subject:

What is a requirement?

 Here are the IEEE definitions of "requirement":

1. a condition or capability needed by a user to solve a problem or achieve an objective
2. a condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard,specification, or other formally imposed document
3. a documented representation of a condition or capability as in (1) or (2)

In laymen’s terms it translates as:

a singular documented need of what a particular product or service should be or perform.

·  Business requirements describe in business terms what must be delivered or accomplished to provide value.

·  Product requirements describe properties of a system or product (which could be one of several ways to accomplish a set of business requirements.)

What types of requirements are there?

Requirements can cover a wide range of needs. For example “we need this by July”; “we want to allow customers to place orders over the web”. As such requirements need to be split into their various types.

The Information systems examination board use the following types:

Functional: What the system should do (i.e. tasks/functions)

Non-functional: How the system should perform (i.e. response times, access restrictions)

 General: Constraints placed upon the project ( i.e. legal, time, cost etc)

 Technical: Hardware and software needs

What are the challenges we face in collecting requirements?

There are many problems associated with requirements engineering, including problems in defining the system scope, problems in fostering understanding among the different stakeholders affected by the development of a given system, and problems in dealing with the volatile nature of requirements. These problems may lead to poor requirements or the development of a system that is later judged unsatisfactory or unacceptable, has high maintenance costs, or undergoes frequent changes. By improving requirements elicitation, the requirements engineering process can be improved, resulting in enhanced system requirements and potentially a much better system.

How do I know when I have  good requirement?

That’s something that is completely open to interpretation. In my  opinion, a good requirement is one that is complete, clear and accurate. It communicates what it is supposed to, without leaving any gaps, and with no ambiguity.

What do we need to document for each requirement?

There are many templates that can be used to document each requirement in a catalogue. Each organisation needs to determine what their content should include to enable them to say what that requirement  does, and gives them something to compare against to confirm that it does what it should. It also gives the customer a way to check what the solution does when deciding how to use the software to meet a business need, and deciding whether the program needs additional functionality to meet a business need.

Can diagrams help?

Yes, it definitely can. Diagramming or modelling helps customers visualise better. It also helps to check for completeness of requirements at an early stage. The saying goes ‘a picture is worth a thousand words’ and when applied to the Requirements Engineering process it allows more to be shown in less space.

Is prioritisation important?

Very much so, prioritisation provides transparency to the business and allows them to make informed decisions when deciding on the scope of the project. In other words, they will understand where the money will be spent and that it is spent on the most critical requirements.

How do we make sure requirements don’t fall between the cracks?

Sometimes with the best will in the world requirements can get left behind in the stampede to complete the project. To stop this from occurring we need traceability. Traceability is one of the essential activities of good requirements engineering. It is used to ensure that the right products are being built at each phase of the software development life cycle, to trace the progress of that development and to reduce the effort required to determine the impacts of requested changes.

Traceability is used to track the relationship between each unique requirement and its
source. For example, a requirement might trace from a business need, a user request, a
business rule, an external interface specification, an industry standard or regulation, or to some other
source.