Working as a Change Agent, you have many different activities on your agenda; and you need to master many different skills.

When I started out as a Change Agent back in 1996 (I have always changed things, but this time my job title gave me the permission), the job description was more or less to write and work with Process Descriptions. What I actually did was something else.

I decided early on to do some research before I could put out a formal Process Description of any kind (we said Process Description, because the actual Process was executed in the Project). I did this partly because it was a new field for me (writing requirements was old but Requirements Engineering as a discipline was quite new then), and partly because I was curious to know what was out there. The result was a 300 plus document that contained most views on the subject. It was not very practical, but people who saw it said that it could work as a PhD dissertation, although I at the time thought that dissertations needed to be more stringent than that.

I didn't communicate this document very well. I just wrote it and sent it to my boss and colleagues and said that they could read it, if they were interested. Few were.

As the organisational impact was zero to none, I started working on a Process Description for a Requirements Engineering process. In hindsight, I shouldn't have. The organisation was too immature for this step. For me, it was important, although the organisation needed something else. It took me an additional six months to develop the Process Description and print it. I was very proud. No one else was.

When the organisation still didn't react, I thought: Well, we have to develop some training material. Slides are never wrong. The result was some hundred slides sent to all corners of the earth (it was a big company). Not much happened. Projects continued to work the way they always had, i.e. more or less ad hoc.

Well, I thought, this time we have to develop a training course. That should do the trick. Over a four year period, I held the course many times, both as a general training for interested pupils and when a project started up. The final version of this training was not the version I started out with. What I thought would interest Engineers and Project Managers didn't work at all. I thought my pupils were interest in theory, the reasons why you should work with requirements in projects. All they wanted to learn was simple tricks and techniques, things that gave proven results: one-two-three type lists, recipes that never failed, templates and examples; and they didn't have much time nor patience to learn it. They were worse than children. The moment they thought I was boring, they would go and read their e-mails. But it trained me. I had to earn and keep their interest. The training got better – far better.

So what do I try to say? When you have written that important Project Specification, or

Quality Plan, or Requirements Specification, or Process Description, you have only done 20% of the work. About 80% is left. All your effort need to be communicated, over and over again, until you are so tired that you want to puke. People should read what you have written, right? They don't. People need to be trained, there should be a conversation about what you teach; you need to be an evangelist for your own ideas and messages. That's what change is about.