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
Wednesday, March 19, 2008
Paper is better than superficial software solutions
In this very nice post, Introducing the Hipster PDA, a good point is made about how practical software-free, paper management can be.In case you want extend beyond the reach of personal management, you may start using cards in full glory:
Getting Things Done with Index Cards
Getting Things Done With Index Cards 2.0
I think that the pictures actually start seeding some doubt that all this paper will end up in a great mess. It's not in serious doubt the usefulness of software for project management in the case of work of more than two people, if the software can deal with the matter at hand, and in particular with limit cases.
My "laws for the usefulness of project management software" are:
- work management software is useful only in a complex work management situation
- work gets complex much faster than any prediction you make (this last is clearly inspired by Murphy's laws)
Labels: useless project management software
Thursday, March 13, 2008
Scrum and re-scheduling
A smart Scrum team leader that is using Teamwork (yes - there is such a thing - smart and using Teamwork) pointed us a practical point: suppose that you are a developer and are assigned a set of issues, on which you do your development and record development time spent. You did with the team the initial evaluation of needed development time, and suppose for a particular issue you decided to put 10 hours.Now you recorded time elapsed, but as happens all the time in life, you have to reschedule some of the issues. Now the users remarked that it is quite cumbersome to reason on the base of estimated duration - worklog done, because all you are actually focused on is time remaining.
So.. here is the change: by clicking on worklog done, a time remaining panel appears, and its editable right there.This little practical change, can make a difference; think when you have planned 34 hours, and have done 27:30, how many to go, will it suffice.. I don't want spend time on that.
This improvement will be included in forthcoming 3.2.4 release.
Labels: scrum practical tools
Tuesday, March 04, 2008
Teamwork sales cartogram
To celebrate our all-time best sales month, February 2008, we created a cartogram of our sales-by-month.Above the sales are just by darker greens, below also the surface is proportional to sales: it's a cartogram, i.e. a map in which area is not preserved.
The algorithm used is by Gastner and Newman's, and the software to generate it is (an adaptation of) cartogram generator output.
We hope to get a lot of transformations from here on!
Labels: software sales graph
