What’s in a term?

“Why is it called a pie chart?”

I was dumbstruck. Here we were at four pm on the second day of a training course looking at the capabilities of Lotus Freelance graphics. We have been working with data for two days, representing it in so many different formats – Bar, line, Bar-Line, Area – you name it, we graphed it – including the Pie-Chart. Here at the end of the course, I get this question.

My first thought is “Has anything gone in?” The lady has asked this question in all seriousness. Behind her a group of young lads are grinning like hyenas that have just detected a nearby prey. I give them my sternest look – as stern as any wounded animal can muster. They calm down – I am still numb. I explain why it’s called a pie chart and pray for the course to end – soon.

Later a colleague walks into my room and asks how things went. “Great group” I said. But you would never believe what I was asked at the end”. I tell him. He laughs. I laugh – now. “This happens to me all the time” he says. “I assume that they know more than they do and they never fail to let me know that they don’t – never assume, they’ll make an ASS of U and ME”.

Training can be cruel, but the lesson I learnt back in 1991 has been with me throughout my various roles since – Never Assume.

Today I still teach part of the time. I teach ITIL, Prince2 and get involved with technical projects are Lotus Domino (usually migration) in either a team or PM role. The lesson still applies.  Even on Prince2 training courses, assumptions are made that need to be corrected. How much work do you have to put in? How much pre-course reading will they have done? Prince2 courses are not an easy ride! The reward is more than worth the effort.

In the early part of this century I was heavily involved in a lot of e-learning projects focussed around IBM/Lotus products – LearningSpace in particular. My role varied from being technical through to product consultancy through to content creation. We had a deployment method based loosely around Prince which was documentation based and supplemented by meetings. One such meeting was a Discovery Workshop where subject matter experts (SMEs), stakeholders and other players would be given the opportunity to put forth their views on content and interaction.

Now I don’t know if it was down to lack of familiarity with the learning environment or the concept of e-learning or downright insecurity, but there were a number of times when I and a colleague had to ask people: “Could you explain that for our benefit please?” or “Can we just clarify your use of that term?” They looked at us as if we had two heads, all naturally assuming we knew exactly what they were talking about. The bigger the acronym, the more we asked. I suddenly found myself wondering “Why is it called a pie-chart?”

This could not be allowed to carry on. So this is what we did. After a short break and the focus of control switched back to us, we split the people up into groups mixing customer and supplier where we could. We then set a short five minute task to come up with as many terms as they felt were relevant to the project. For example “What you understand by the terms: content, compliance, LMS”. We then consolidated the terms on the board – nothing was ruled out. When a term went up on the board we would then ask someone from a different team to explain what it meant. This way we would be more likely to get collective agreement and sometimes we didn’t!! We also bravely tackled some of the management-speak that had been floating around the room. Terms such as “Effective” and “easy to use” were explored.  As I was writing on the board, my colleague was documenting these as part of our project definition which we fully intended to get the customer to sign-off. We also gained a useful insight into the customer with this exercise. There were quite a few places where they themselves had wrongly assumed a terms meaning.

So what is the relevance to Prince2? Prince2 makes reference to assumptions in the Project Initiation Document (PID) – the main working document for the project. It is logical that assumptions regarding term definition should be included here. However there may be certain matters of confidentiality that prevent it being shared with suppliers. I am sure you can all think of items that should remain within the remit of the customer. In our case, this was not an issue with this particular customer but it is not a universally open document. So to be consistent and fill the gap between PID and supplier, we created a Key Terms Definition (KTD) document. The KTD listed all agreed technical and assumed terms between the parties. There was a consensus on the terms, their meanings and application. It was about two sides in length and it was requested that it be subject to strict control (formal change and configuration management). As we became more involved in e-learning projects, the KTD became increasingly central to our engagement. It helped in empowering stakeholders and players, but also reduced some of those horrible exposures that can crop up in handover and review. It was more significant than a glossary – it was a small control and it worked.

Anyways, in case some of you are wondering “Why is it called a pie-chart?” Well it does look like a pie!

Posted in SkillSolve | Comments (0)