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.
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?