Now this simple challenge made me think about monitoring and control in another perspective: instead of fine tune a set of processes and tools, why not start with your objectives? Why do you need to control those actions in the first place?
In this article you'll find some ideas on how to approach monitoring and control even when the classics tools seem not to fit your needs.
Why do you want to control your project?
So why do you want control over your project? Some of the following may apply to any particular project:
- You want everyone to know the progress being made
- You have to know how much will the project cost at the end
- You have to know when the project will really end (schedule)
- You need to know what is changed along the way
- You want to anticipate any problems that may arise (risk)
I always capture progress as it is one of the strongest motivators, not only for your team but also for yourself. As it turns out, knowing how much progress is being made is a stronger motivator than some bonus (at least in general and in the case of intellectual work). Motivation doesn't play a part in control but it makes your project better altogether. Check this Harvard Business Review article or the video bellow for more on motivators. Oh, and this previous article published here too of course, "Mastering Motivation"!
Bosses, and in particular sponsors, also like this progress thing a lot. Not only because they're motivated themselves as they actually see that work is being done and stuff accomplished, but just because they know what's going on. And the worst thing that can happen to a sponsor is being asked something about a project and they don't know how to answer.
You can show progress in many ways. Kanban boards and burn down charts are some of the trends these days but Gantt charts can also show progress. Even Earned Value Management can do that for you. You have plenty to choose from and choosing one or the other at least depends on the context, your knowledge and experience, the type of project and team. Using burn down charts with a 100 people team will probably be a bad idea as it will be very challenging.
Predicting the cost at the end of the project, how much it will actually cost, is something that can be crucial. Namely, if the estimated costs of your project are near the point where it doesn't compensate to do it. Or if you actually don't have that many resources available. I have been in this situation just a couple of times and I controlled these projects using Earned Value Management. It's more hard work to implement but it does get the job done.
Showing progress is also important as it's a motivator, so it's a good idea to turn it public for your project team.
Ever had a deadline? That's one reason for you to pay special attention to the schedule. Beating your competitors is another. The tools that apply to costs all apply to schedule too. There may some other tools to help you with schedule alone but unfortunately I don't know of any. Drop me a line if you can help me with this one, will you?
Controlling the changes will be of the utmost importance if you're project's results will be the starting point of some production process, or the starting point of another project or included in a program. In any case I must alert you that the purpose of change control is never to prevent changes, OK? It serves for you to measure the impact of changes (may they be in cost, quality or whatever) and make a decision about it.
The only way I know to address change control is to implement an adequate change control process. This alone is the topic of several books, so you can imagine the complexity of the questions related to change control processes.
Sometimes you get projects that are really break-through. I love these ones as they're really challenging but the overall risk increases dramatically for the simple reason that you don't even know how to build some of your project's results. And if they're really, really break-through no one in the world knows how to build those...
The first thing you want to do in these cases is to time-box those activities that you don't know exactly how to do or that you need to explore something. To time-box activities means to allow a maximum amount of time to be spent at the end of which you decide what to do about it. This alone limits the losses.
And another thing you can do is to devote some time of your team to explore the possibilities of what's being done and what can go wrong - a bit of risk identification can be beneficial.
But in the end...
It's all up to your own particular project context. I confess I've never seen much of this about needs behind project control on books but I hope this article can be of use to you. What I tried to do here is to look at project control in terms of what you need from it as an end result. Depending on that, one approach or the other could be best suited for you. But as long as projects produce unique results, each project will be a particular case and you'll have to take a close look at each one.
Images from http://www.barco.com
Posted by Luis Seabra Coelho