EVOLUTION OF BPR

Human aspects of Project Management

Posted on the July 1st, 2008 under Change Management, Enterprise 2.0 by Gregory Yankelovich

One area where Enterprise 2.0 technology makes dramatic inroads is Project Management tools. There are many web based Project Management and Time and Activity Management software based on “social software” technologies available now. Personally I have always maintained that there is no need to manage competent professionals, they can use thought leadership, support, sounding board for discussion, but not management. Therefore I had to maintain time lines and budgets for the projects, largely by “keeping a ear to the ground” and using anything from spreadsheets to MS Project for management reporting and accounting.

A few years ago I discovered a dotProject Open Source software, which is built on the collaborative/wiki model base. Despite a pretty primitive user interface, absence of security/privacy boundaries and fair number of bugs at that time, the idea or participative project/team management experience, made this approach very appealing to me. It took a few days to install, to learn and to set up projects, teams and users within the program. The adoption by my teams was a very different experience - people with direct project responsibilities, started to use the tool the same way they would use MS Project, but their team members would not contribute by documenting and updating their tasks voluntarily, and only use it as a repository of supporting documentation and versions release management. The visibility of the projects status improved the quality of my communications with project managers and the project’s customers tremendously, but it fell short of my hopes for team members engagement.

Since then, I have attempted a few times to introduce this or similar tools in projects where I did not have administrative authority to enforce the adoption, but these attempts were always met with resistance. A few times team members suggested to use a generic wiki as a project management environment, which puzzled me and when I agreed to experiment, the results were pathetic - the team would relapse into the traditional model: PM used MS Project to maintain time lines and resources, wasted a lot of time to convert file formats for reporting, and team members reported their time via spreadsheets and documents. The only use they found for wiki was to dump documents and other incidental materials, and even that got old very soon. So much for “social” software!

Here is my interpretation of the lessons learned:

1. Forget what I said before about management of competent professionals - no professional is competent enough not to be managed. Our competencies do not account for simple human weaknesses - most of us do not like to make commitments and we like even less to be accountable. The inherent problem lies in the fact that positive results absolutely require commitment and accountability, hence we all perform better under competent management supervision regardless of our titles.

2. We need much more definitive definitions of “community” when we consider/plan implementation of “social software” unless we do it for entertainment. If you have any purpose in mind for creation of a “community”, you better define boundaries, rules, roles and responsibilities of participants or you are wasting your time and resources. It seem that any “living” organism needs a structure to grow.

3. Adoption management for “social software” seems to be an oxymoron, but I would propose that it is even more critical for success than many hated process-bound applications. If it does not provide personal value for every participant, the participation will not be maintained unless mandated and managed for compliance.