Monday, March 31, 2008
"Project management 2.0": keep projects simple, but NOT the software
 | And some other links: |
Just imagine the dictatorial project manager, lone with his ugly and hugely complex MS project file, that is imposing work to all his slaves; he has a huge salary, and his employees/slaves are kept in the most economical working conditions, with strictly the most limited information access compatible with their doing their assigned job. The Gantt chart gets printed, with hundreds of tiny unreadable lanes, all sort of dependencies, attached somewhere on the wall, and totally ignored.
It is a diffused knowledge in software development, and by now not only there, that this kind of a-priori top-down centralized management most of the times leads to great failures.
There have been all kinds of reaction to this situation: agile methodologies, good working conditions, unlimited access to information, distributed planning and work logging application, dynamic “runtime” work reporting tools that allow real time planning evaluation and reaction.
There is one conclusion to be drawn: software-aided work management owes its occasional success mostly due to team continuous adoption of the software tools, instead of the a-priori drawing of a Gantt chart.
Adoption is possible if all is done to facilitate it: it should allow very simple data insertion, it should not force data duplication, it should be all done “in one place” whenever possible, it should present the most relevant information without making the user “chase” it.
Now anyone who has even little real experience in software-aided project management, is aware that work management is never simple, and things most of the time turn out to be more complex than planned.
The same happens when you start to use a software: if you remember the wonder sensation when you first started using Excel (I do), how naturally it did make data fit in its simple model. And would you ever have imagined that all the export, import, calculation, graphs and all those other functionalities would have been so useful? That you, not just an imaginary user, would have used them so many times? The fact is that good software must be provided in advance of cover for many, many, many limit case uses; this is something that the current Web 2.0 discussion is ignoring. And should provide also some easy way to expand functionality. "Keeping project trees simple" does not at all imply that you need a powerless software to manage work. Even small groups’ work quickly gets complex, and involves issues, documents, a shared agenda, meetings, and you won’t be able to make sense of this by using a hundred different, separate, immature social web based solutions.
Let’s consider security problems for even a medium-small company, say with a hundred employees. I bet that no one can find a single example of such a company where everyone can see all the information floating in the company in the IT structure. But more: there will always be local exceptions to a simple role-based security model, because there will always turn up a particular project that has its own security: its limit cases are the killers, and you need powerful software to cover those.
Another typically ignored fact that makes the discussion about Web 2.0 a bit ethereal is that today software does not get adopted in a void, in particular if we are considering business oriented software. So a “deeply intimate” software choice like that of a project management application must consider how will such software interact with existing one, like the old AS-400 accounting application, how will it comply with data privacy and so on. Using a closed box online webapp is simply not a solution for most cases.
Microsoft Project, but also "web 2.0 project managent", are deeply incompatible with all the above considerations. Project management 2.0 concerns the methodology, and also the software, but nothing of the sort of "web 2.0 project managent" can be the answer.
Our Teamwork is structurally compatible with the above, though certainly not perfect from the point of view of fast access of information: but this improving this is the target of coming releases. Maybe it will not be the killer app, but at least we start from realistic considerations.
Traditionally large companies got their work and project management software as a custom solution. What hasn't been realized by both developers and reviewers is that there is no difference in needs that a custom and not custom solution must satisfy. And the difference in IT needs between large and small companies is getting thinner; but the solution is to bring the qualities of a custom solution of a shrink-wrapped one, and not the other way round!
Some of the things one can do with a locally installable version and not with a “Web 2.0 online service”: install it on https, integrate it with a single sign-on service, integrate it with application server authentication, connect it with custom file server services (like FTP), integrate it with versioning servers (like SVN), integrate it with LDAP, various synchronization services at database level, integrate with job scheduling services, …
Labels: agile project management, project management 2.0, web 2.0
Most of the times a Gantt is a plan - in the early stages of a project - and a dream afterwards. Whatever the tool you use, if it doesn't reflect reality you're doomed.
So you've got to make it easy to keep the status up-to date: by reducing details, and by empowering fast updates and changes with a good GUI. This is what Web 2.0 tools are doing. Although my agile mindset tells me to use a wall as much as I can.
I think many of "PM 2.0 tools" are sometimes making heavy cuts to the software complexity, to make PM tools attractive to markets which are (so lucky to be) not Gantt-savy. So you can use them with a more interesting learning curve.
But you're right on the "island" assumption. In an enterprise scenario I cannot assume that there is no other software in use, and integration points will help a lot. Where the Web2.0 approach is interesting (but could still be better) is in cross-organization project management. The moment I cross the boundaries of a company I CAN assume that I am on an island, because integration with many different systems would be not worth the price, for small or low-tech projects.
<< Home
