It’s surprising to see how many people confuse between the two and use these two interchangeably. This can lead to confusion and even issues while choosing the most appropriate solution for ones needs.
If you are talking about online Project Management software, then important aspects of project management have to be incorporated — like task scheduling, gantt chart reporting, resource scheduling, ability to track project timeline and milestones. Without these core features, the solution could probably be a online file share platform in a central place
If you are taking about Project Collaboration software then aspects like file sharing, file check-in/out, discussion forums, issue trackers, task assignment etc are central to the solution. Aspects like access control, email integration, mobile interfaces also become important NFR areas for such platforms
In an ideal world, (and from a project perspective, everything is one project) there should be single platform for both project management + project collaboration. There are few solutions that provide the amalgamation of the two but still one needs to be aware of which part is what.
Imagine a frog and then imagine a pan of boiling hot water. Now imagine that some crooked mind lifts the frog and puts it in the pan of boiling hot water. What do you think will happen? Yes, the frog will jump straight out of the pan within a faction of a second (if the lid of the pan is not closed).
Now imagine the same frog and a pan with room temperature water. Now imagine an even more crooked mind leaving the frog in that pan and putting that pan on a burner with a slow flame underneath it. What do you think will happen now? Yes, in this case the frog will not jump out but will feel at home in water.
Now, over time, the water in the pan will get warmer. What do you think frog will do? It will feel even more at home; feel happy at the warm water giving it a gentle massage to its skin & legs.
Now the crooked mind increases the flame and slowly the water starts getting warmer & warmer and then hot. What do you think the frog will do? As the water gets warmer, it will feel happier but it will not be able to realize when the water has become too uncomfortable for its own good. As the flame gets bigger underneath & water gets boiling hot, the frog will have lost all the energy in its legs to jump out. Its mind will tell to bail out but there won’t be any energy left in the frog and it will continue to be in the pan and face a slow death…
So, what has this got to do with project management & project managers?
Well, analyze carefully and you will realize that there is not much difference between a frog & the most project managers. There is also not much difference between the pan (with water) & the project environment. Most project managers, if asked to take over a project in between, would know how ‘hot or cold’ it is and then take appropriate action. This is just like the frog being put in hot water and it taking immediate action.
However, what most project managers don’t realize the 2nd scenario they land up in — where they start with water at room temperature & the water gets warmer at first and with the flame getting bigger over time the temperature under the collar gets soaring. At the start of the project, just like the water in the pan at room temperature, things look perfectly in control for the PM – a small team, key members staffed, not much confusion.
Things remain fine for some more time (till the water is warmer) but somewhere down the line things just implode and before the PM realizes things have gone out of hand (water is too hot, in the pan, for the frog to take any action). There are quality issues, builds are failing, customer is dis-satisfied, the team is unhappy & clueless, senior management is watching with eagle eyes, your family life is ruined and while driving to office you wonder how things came to be where they are today…
You wonder how & when that excellent Tech-Lead became a bottleneck & the go-to person for even small things – such as from where to setup the development environment or which version of IDE to be used with what plugins — you wonder why the leads are spending more time in answering routine questions & forwarding emails rather than doing their actual work. You wonder why the testing team doesn’t have access to the latest requirements in order to prepare the test cases. You wonder why the same question is being asked and answered a gzillion times. You wonder why customer wants you to resend the status update report of last month. You wonder when this project will end..!!!!
The fact is that we don’t realize or observe or are blind to the small changes happening around us and the long term impact of these small changes. Many downstream issues are caused by our inability to react to significant changes that occur gradually. And in today’s era, nobody pays attention to anything ‘small’ unless it is on fire or priority#1. Everybody loves a hero – a person who turns around a losing situation into a winning one (organizations reward people who get troubled projects back on track but not necessarily those who avoid trouble and go unnoticed.) Because changes (from room temperature to warm to hot to boiling hot) happen so slowly that they go unnoticed and you are then left to wonder where and when things went wrong.
The irony is that it is not just first time PM’s who fall for this. Experienced PM’s also fall into this over & over again and then blame the ‘system’. Great PM’s foresee & preempt the ‘upcoming changes’ and plan accordingly. They plan like good chess players – several moves in advance and multiple scenarios. They manage the environment of the project accordingly to prevent the effects of ‘global warming’ within the project. Such PM’s ensure satisfied customers, happy people and predictable outcomes.
So, how can PM’s foresee & preempt the ‘upcoming small changes’ and prepare well? What can they do? That’s for another post 🙂
The innovation & KM unconference is being planned for the 9th July 2011 in Bangalore on the 9th July 2011 @ MindTree Ltd Campus in Whitefield.
This will be a gathering of practicing KM & Innovation professionals for discussing topics that are important to KM & Innovation professionals and get insights from fellow colleagues in an informal environment.
In true unconference style, there will be no KeyNote speakers or Chief Guests. All topics to be decided by the participants themselves. So everybody is requested to actively take part by contributing to the event wiki with your ideas!
The list of suggested topics to be discussed is quite interesting & relevant for the innovation & KM professionals.
- Why KM alone will not work. KM need’s to collaborate better with other departments KM Systems.
- Why “build it and they will come” doesn’t work
- Compliance or Adoption: Key to success of KM
- Everyone, including their Mother-in-law & their dog has an opinion on KM/Innovation. Challenges for KM/Innovation professionals
- Social/Web2.0 Systems & approaches to KM & Innovation. Have they delivered?
- Boot-strapping KM & Innovation within organizations without formal mandates
- Future of KM/Innovation professionals. Is there any; beyond content management?
- Reality Check: The organization cares two hoot about KM and is just a ‘nice to have’ function
- Communities: In the age of internet & google, what’s the advantage of communities within organizations
- KM for Project Delivery & Large Accounts
- Innovation 101. What are we talking here? Innovation in IT Services business? You must be joking
More details here on this barcamp wiki page
Google Map for the MindTree Office
Dave Snowden in his address on Social Computing & KM during the KM India summit brought about a point on how current organizational structures are not suited for creating social networks and hinder performance. Dave explained this with the Matrix Organizational Structure where people have multiple reporting relationships and no one is sure which way their loyalties should be.
Dave talked about the “Crew or Military Model” of team formation which he termed as more adaptive in nature based on the concepts of “Role” & “Expectation of role”. He explained this with an example of how teams are formed in airlines or ships. People who may or may not have worked before come together to form a team and work as a team based on an understanding of what each persons role is and what to expect from that role.
In the IT industry this model, in intent, is a model that most software development organizations ‘aspire’ to implement while creating teams for developing software. I believe that in theory this is a good concept but there are several questions that need to answered and various soft aspects thought.
- “Crew” model would work for teams where the tasks are repeatable, tasks which have little room for variation and have to be done “the same as before way” on time. Tasks which have the procedures defined and the job of the person doing is to just follow the procedures and do it. For example; airline crew. pilot, co-pilot, air hostess, stewards, checkin counter assistants. The kind of tasks involved are routine, repeatable, well documented, and need to be performed with precision every time.
- In the software industry, for example each development project is unique and the development life-cycle is ‘not predictable‘ to say the least. To compound matters, skills required may not be available and training may have to done while on the job. This is not the case in crew model where almost all the times things are predictable and follow a predictable sequence. For example, in an airplane you can predict what would happen from the time you take a boarding pass and go to your seat to the time you get down from the flight. It is all very very predictable, linear & sequential. There is no room for variation — unless it is a private chartered russian flight 🙂
- Though one may say that even in software development we have roles like PM, Technical Leads, DBA’s etc etc and we know what is expected of that role. However, the reality is that software development is an iterative, some what chaotic, emergent process. There is a complex interplay between all stake holders to create the ‘intangible’ software that people want. Now by very nature of their business, airlines/ships can’t have an iterative, some what chaotic, emergent process to the nature of work that teams do there. Imagine a team of air hostess emulating an iterative, some what chaotic, emergent process to serve the passengers.!!!
- Another important element is the “customer engagement” in the whole development life-cycle itself where requirements are fluid and can keep changing. Now one could argue that even in a ship or a airplane there is engagement required with the customers, but that engagement and the choices available and hence the options that the crew can exercise are from a limited set that is almost well known in advance. It would be only in an adverse situation of a ship capsizing or a plane mishap (e.g. hi-jack) that the engagement model between all the participants becomes fluid and relatively unknown.
- The most important aspect I feel is the “nature of work” itself. By very nature, software engineering calls for continuous learning & updation of skills while on the job. This is not necessarily true for airline or ship teams. Not to say that they don’t need to learn or improve their skills but that is within a very narrow band and at a slow pace than in software engineering. This aspect leads to totally different behavioral, motivational, aspirational & emotional factors within individuals that then influence people, teams & how they work.
- I also think that teams in crew models the teams need to “coordinate” with each other to perform the task whereas in software development teams need to “collaborate” with each other to perform the task. These two things may look similar but call for totally different actions, engagement models within teams.
The above are just some of the many questions out there. What do you think?
Would ‘Crew or Military’ models of team formation work effectively in software developments? What could be other challenges and opportunities?
Quite a few experiments, like counting the number of coins in a jar & guessing the weight of the cake have been conducted to test out the ‘wisdom of crowds’ concept. Recently I got a chance to conduct an experiment at a gathering of approximately 150 people — all software/computer professionals
We put up a jar filled with éclairs and asked the audience to guess the number of éclairs in the jar and note it down on a piece of paper and hand it over to us. Obviously, we were excited to know the results – if the experiment worked, did someone guess the correct number?
Here are the results:
We had responses ranging from 25 éclairs to 786 éclairs. The actual number of éclairs in the jar was 204. Out of the 134 responses, only 1 person got the number right. The average, the ‘collective wisdom’ of the ‘crowd’ was 161.4 – an accuracy % of 79.14.
The results have left me wondering as to why did the results not concur with the ‘wisdom of crowds’ theory. After all, the following elements of ‘wisdom of crowds’ were present in the experiment:
- There was enough diversity among the participants. even though all the participants were software engineers, they came from different project teams, had varying levels of experience, roles etc.
- Each person was making his/her own independent choice and was not influenced by any other member
- There was means for us to collect and aggregate the responses.
The fourth element ‘Decentralization — people being able to specialize and draw on local knowledge’ can be debated to be missing from the experiment. How can we assume that there were people specializing in guessing the number of éclairs in a jar? How could they draw on local knowledge?
In Galton’s experiments, there were people who were butchers and farmers who one can assume to be specializing in ox/cattle. In ‘Guess the weight of the Cake’ experiment, people could feel the cake in their hands, there were people who were traders and hence one can assume that ‘knowing the weight of an object’ was something that they were familiar with.
The ‘guess the number of coins’ experiment was an online experiment and had no option for people to see, to feel the jar, hold it in their hands. Similar aspects were present in the experiment we conducted – we just showed people the jar filled with éclairs. We did not have people holding the jar, touching it, feeling it. Could such seemingly insignificant things allow people to make more informed choice? I don’t know.
BTW, ‘Guess the weight of the cake’ experiment was 99% successful even though it had just 120 participants whereas ‘guess the number of coins’ experiment was just 88% successful even though it had 1760 participants. This indicates that while the sample size could be a factor, but it does not seem so in the above examples.
I am wondering if aspects of ‘cognition, cooperation, coordination’ are present in such experiments?
What about the sample composition itself – all software/computer professionals? Do they bring diversity or are software professionals just not the right sample for any kind of experiment?