The whole thing came about because we have an inconsistent approach to PM in the wider team. That inconsistency makes hard work for all of us.
- we cannot easily see who is working on what
You might say, a classic resource management issue. Actually it is not. The team leaders have a very good understanding what the workload of their guys is and what they can add or what has to wait. No, the issue is different. The people in the other teams don’t know that workload and as such their expectations to get things done is not matched by possible actions.
- we cannot report on project progress consistently
This is a tool issue in the first place and probably the easiest to address. Although during the workshop we discovered that we have a different understanding when a set of tasks becomes a project. The Service Desk for example works mostly on incidents and problems (= complex issues) and sometimes on projects. Projects for them is when the time commitment is significantly more than 3 working days. Development is mostly working on projects and partly on improving things or fixing bugs. A project constitutes when a business owner has a clearly defined set of requirements that results in a set of deliverables. For the application project leaders the definition sits somewhat in the middle. They prefer a definition based on the $ value and usually apply the term project to everything that is “new” or a significant change.
This makes it hard for us. We take on more “projects” or complex tasks that we should. As a result we struggle to deliver. At the same time the business is not helping by leaving it to us to translate a one sentence “need” description into actionable requirements. Recently we adopted scrum and agile approaches to ensure this translation meets the expectations of our customers.
We are now developing a common understanding what constitutes a project and how we make all current ones visible.
We also want to provide our customers with a guideline what we expect and need to deliver the best possible outcome for them.
If you provide such services for your internal customers very successfully, how do you do that?
Re-reading what I’ve written you guys must think we are nuts. Don’t we know what makes a good project? Don’t we have a project management process? So, I need to clarify this. Yes, we do know and we do have. The issue occurs in the gray zone between a set of complex tasks where one person needs some help and those mini projects where a full blown PM approach is a terrible overhead.