“Really well” I replied, “you just need a new one for each project you are on.”
My answer didn’t seem to go down well though. After all, who wants yet another piece of administration to do?
Then we discussed the problem that both permanent staff and contractors often have with projects. Contractors get no real feedback on how they are going until their contract ends, while permanent staff have to have a series of discussions based on a document that bears little relationship to what they are doing on their projects.
So the problem really seems to be that while we are completing lots of documents and having some meetings about them, BA’s and testers, in particular, get very little relevant ammunition to include in all those documents and meetings.
So here is what I propose as a starting point:
- If you are a contractor, skip this step. If you are a permanent staff member in a consulting team, do the most generic annual performance agreement you can get away with.
- Choose one of the options below
Option one – the totally minimalist performance agreement
Fill in the answers to the following questions:
- How can I, in my role (“some title for my role”) provide (“What do they need from me on this project?”) to (“Who is the recipient of what I am doing?”) so they can (“What can they do better because I am there – make a better decision, be less stressed, be able to do better work?”)?
- Who will notice what I am doing (ie who is the recipient above ) and how will they know if I am helping them?
Now go and speak to the (alleged) recipients of your work and see if they agree with what you have come up with. Then get them to give you feedback on what you agree to.
This will at least allow you to have some evidence that you were adding value on the project.
Option two – Checking if you know your priorities
Projects are like shifting sand. You often turn up with a clear role profile but within 10 minutes it has been replaced with “whatever it takes to help the team deliver”. Then a month goes by and you are left wondering what you did with all that time.
So I like to do a role profile like this one (all on one page) based on the questions in option one:
- My role is (blah), which means I (verb-noun). For example, I am the BA which means I collect requirements.
- My most important 3 responsibilities are (a, b then c in order)
Then I take this role profile to the PM and to my line manager/account manager and see if they agree. Strangely I find that they usually disagree even on this simple list of what I am doing. So I chat for a while to clarify everyone’s (current) expectations of me.
Then, when things change and I get extra missions or scope creep I compare it to my top three priorities and see if it is aligned to them. If it is then great and if it’s not then I just ask myself if it will impact my ability to deliver on those three priorities.
If my scope creep will impact my ability to deliver on my existing priorities then I mention that impact to both the PM, the key recipients of my work and my line manager in my next catch-up with them. This is not to say I won’t do it, but to make sure everyone knows what I am focusing on. Simply reminding them and I of this keeps me more focused and clarifies when I am going to de-prioritise other work.
Finally, I come up with a goal for myself for the project. This is not a goal to benefit the company (though it might help them) but one for me to keep my own focus on so I get a benefit from the project. For example:
- I will (blah) by (date) so (my own reason). I will measure my progress by (blah) and reward myself with (something I can do myself) when I succeed.
- I will learn how to use the automated test too by the end of phase one so that I can expand my skills. I will measure my progress by measuring whether I spend time using it and getting feedback from Mary on how well I am using it. I will reward myself with a muffin after the release date if I can create and run tests without support from others.
I often communicate this goal because others might support me in doing it.
I have found that doing that much work gives me a good basis for getting feedback, knowing where I stand, improving my focus on what others think is important and having people give good feedback to my boss.
And YES, I really do go through this for each project when I am on multiple projects. In fact the more muddled my day, the more these discussions keep me focused and keep others aligned to what I am doing. It also gives me something to talk about other than the cricket when I catch up with my boss.
Not sure if others do the same but I have definitely found I get better feedback when I do this (better as in more useful and more positive).
Posted by James King