How do you make sure the "level of ambition" is the same for your project members, i.e. that the tester doesn't put to much efford into testing if that isn't required by the project owner.. or the architect creates an architecture that's to generic for the purpose?
So, how do you communicate this "ambition level" to the members?
and how do you measure/monitor the progress?
I hope this makes sence.
Thanks in advance,
Svend Rost Saving Changes...
Robert ProlProject Manager| KPMG LLPEast Sandwich, Ma, United States
My impression is that you have two issues going on. One is trying to get people who are all wired differently to work the same. This isn't easily fixable, nor do you necessarily want to fix it. Each person is unique, and will bring strengths and weaknesses to the table. Know your team members, and how they work. Leverage strengths, and coach through weakness. Think of a team member's weakness as a risk, and have a plan to manage it.
Know your own limitations also. I know that I am good at some things, and other things I need to work extra hard at. I delegate things that I am not good at when I need to, and focus on my strengths. (I do focus my PDU plan around weaknesses.)
The other issue sounds like a planning challenge. A sound project plan will have clearly identifiable objectives. If your issue is with testers, a testing plan will keep them within parameters. I've often asked testers to break a product, and many times asked them to just give it a quick pass. It depended on the project needs. Documentation keeps people focused. Lack of documentation provides team members freedom to make the project fail.
Hope this helps.
Saving Changes...
Rob MartinConsulting (Contract)| Microsoft (Thailand)Lam Luk Ka, Pathum Thani, Thailand
You have to put as much time into team communications, roles responsibilities as you do with the customer and sponsors.
When the project is started, the team members need to be informed exactly what is required of them, what levels of quality are expected etc. If you have team members (which is what I suspect here from your OP) that are prone to heading off on their own tangents (or rabbit holes) then you need to make sure that you spend more time with these team members when it comes to planning and then execution.
For a tester, there should be firm testing requirements and these are detailed and communicated to the testing team. An allocation of time should be sufficient to complete the task.
Rob
Saving Changes...
Communicate the business benefit of the project clearly and loudly. Convince the team that they're working on something that benefits not only management, but themselves. Give anyone a simple list of tasks and they'll think of it as "just more work." But throw a good business case and bang for the buck in their face and they'll feel a part of something, not just cogs in a project machine. Saving Changes...
