In Thornley’s post Social Project Management: Everything is Small Again which got me started, he has two lists of the “hallmarks of social project management (2.0)” vs “project 1.0 focused on large projects with large budgets and enormous teams”. Just contrasting those two in that way sets the discussion up to head towards a foregone conclusion; Smaller is easier to manage. Yet many projects are large projects and dorequire large budgets and teams.
A better question is, “How can we facilitate strong and healthy social interaction on all projects regardless of size/budget/staff?”
First let’s get some commonalities out of the way…
While they appear only on the social project management list, the following apply to projects of any size, so I’m taking them off the table for the purposes of this post:
- Smart, motivated people with multi-disciplinary skills.
Yes, all projects should have these.
Again, good for any project not just small ones.
- Rapid release: Take it out to the community quickly and ask them to participate in alpha and beta testing.
- Feedback: End user feedback is sought to refine the product.
- Responsiveness: Speed and close contact with users leads to quick reaction to feedback.
- Minimal scope: Less is more. Build less.
Nice buzz-phrase, but really more is more. However there is wisdom here. A series of small projects (less) can deliver more when repeated many times. Perhaps this should be “Build less at any one time.”
- Limited planning. Non-essential documentation and highly detailed specification are dispensed with.
This is kinda like saying, “Don’t do non-essential tasks.” It is true for any size of project.
- Expected failure
In projects of any size you can end up with expected failure when the schedule is unrealistic for the scope and resources. This is certainly a morale killer. But it is not limited to large projects
Now let’s look at some of the meaty problems with social project management in large projects.
Let’s get Small(er)
Breaking large projects down into smaller projects is an excellent way. In fact, Reichelt made a point of this in her presentation (though it does not appear in the derivative posts as other than a footnote). The issue, once you break the large project down, becomes tracking and coordinating all of those sub-projects that make up the whole.
This amounts to coordinating the efforts and communication and interaction of many people. This is a social activity.
Planning and Scheduling
Schedule actually does matter. You must set expectations with customers (either internal or external) on when your project will be completed. Business strategy often hinges upon your ability to accurately and reliably predict project schedules. Communicating those schedules and expectations is a social activity. It is why traditional project management tools that treat the schedule as somehow outside of the project itself, with no integration with discussion and notes and design is so… well… anti-social.
Long-term strategic planning requires something like horizon & beyond timelines. Planning a project now that will be useful and realistic in 18 months does not work at all if the project plan does not get updated anytime in between. Plans change, people change, organizations change, and the project plan must change with them or the schedule is surely junk.
However you schedule, it must be able to adjust effortlessly to fast pace and constant change. Gantt charts are simply a representation of the schedule that when mixed with single point estimates become poison. The optimism of these schedules (noted by Reichelt) and their lack of resemblance to reality spring directly from the way that the estimates for the individual tasks are collected, processed, and updated (or not updated as the case may be).
In order to get good, reliable schedule updates, there must be something in it for the person performing the update. They must be comfortable making the updates in real-time as they get improved information about their tasks on the project. It must deliver value to them independent of getting their boss off of their back. Otherwise all you get is grudging compliance and garbage data in the system.
Which brings up…
One of the key difficulties noted in managing large projects is that top down organization leads to an extensive hierarchy. Information trickles down but getting the information back up is difficult. Really this should be thought of as a pure communication problem (hmm… communication between people, social?).
If everyone can instantly see how changes (like scope creep) and trade-offs (like cuts) affect the schedule then the many stakeholders problem where the scope grows and grows from competing interests becomes easier (not easy, but easier) to manage.
The Wrap Up
There is little difference between the “social-ness” of small projects versus large projects. Social project management in large projects is not significantly harder than in small projects if you have tools that scale well and facilitate:
- decomposition of large projects into smaller sub-projects
- coordination of those smaller projects, and the aggregation of status and schedules for those smaller projects back into a large project view
- flexible schedules supporting ranges of outcomes that encompass an uncertain future for realistic planning and scheduling
- active participation by delivering added value for each participant in the project from the project sponsor all the way up to the front-line worker doing the day-to-day tasks
- open communication and complete transparency with instant or near instant updates and communication of changes to all team members and stakeholders