My long-time blogging friend, Jim McGee, will be teaching a course on project management and has some thoughts on how to enhance the course this time around. Some of the things he is thinking about scratch an itch for me too.
His main question in Design projects before worrying about managing them is "We would do a better job at managing projects if we spent more time designing them first"?
As Jim describes, I find that in many cases people are presented with a project ("Implement XYZ" or "Fix ABC" or "Build this") and they believe that the fastest way to get the project done is to just get started doing the project. The sooner we start, the sooner we'll finish.
The difficulty that Jim is pointing to is that project teams often don't know what "it" is. Sure, they've been handed some directive, but often path to getting there may not be as clear as it seems on the surface. Or even - something I find more pernicious - the directive itself may not truly solve the problem that the business has. So they get the result of the project, but they aren't happy because it isn't a complete deliverable from the business perspective.
Stepping back from "doing the project" and thinking about what the project should deliver is an important part of thinking through what the project should be. What is the project meant to do? Will the directive we've been handed really do what the business needs? What else does the project need to deliver in order to realize the full business need?
A simplified example: A project team is setting up an online / cloud based procurement system. They know what steps are required to enabled the technology and get the right data fed into it from the various suppliers and internal systems. And they are ready to go.
But then ask why it is that this new tool is being setup, and what do you learn? The current systems for procurement are slow and so prone to mistakes that 80-90% of the procurement requests get routed to a human being at some point (making it slower). If they could turn this around so that fewer than 10% of the requests need to be touched, the added speed and simplicity would enable the purchasing organization to get better terms with suppliers and further simplify procurement processes.
So now how does this change the project? Not only is there a new tool to be setup, but there are also other changes required: How to ensure people use the new tool (and procedures), instead of simply going back to the old way? How to check that the new way of working is creating the desired result? How to setup ongoing improvement of the new way of working? How to shut down old systems? etc. etc.
There are many ways to go about this. The approach that has arisen from agile software development has the team putting something as small as possible together and testing it together with the customer. I am fond of the Product Flow Diagram that shows how the deliverables of a project (or program) link together to create the overall value behind the project.