Project Management

Articles related to doing projects right

Project documents or online repositories (Part One)?

When designing project delivery methodologies, we are faced with the decision of whether information should be housed in standalone documents or in online repositories. While there are those who view this as a binary choice, I would advocate a hybrid approach. Assuming we have or can procure or build underlying tooling support we can then choose to host some information centrally and utilize standalone documents for the rest.

Before proceeding too far with any of these options, it’s important to understand the advantages and disadvantages of each so that we can pick the right approach for each need.

Benefits of a document-centric approach include:

  • Low cost of implementation and limited training requirements – whether it’s MS Office or a competing suite, most organizations have already deployed the basic desktop applications needed to support creation of project documents and the staff who will be working on projects are usually sufficiently competent with the use of these applications.
  • External stakeholder access – as vendors and other external stakeholders are quite likely to have the desktop applications used to create the project documents, there is little difficulty in sharing these documents.
  • Ease of providing guidance and examples – project document templates can be created with structure and guidance to facilitate appropriate usage and examples of properly populated instances can be easily shared.
  • Approvals and versioning can be implemented easily – it is not challenging to conduct reviews and get approval using standalone documents, and taking a snapshot or baseline of a document is fairly simple.

However, there are some drawbacks when using documents to house project information:

  • Collaboration is challenging – while documents can be easily shared, the desktop applications used to create them don’t lend themselves well to having multiple contributors collaborate to create a document. Attempting to do so in a distributed manner often leads to document corruption or overwritten changes so invariably one person holds the pen or a game of hot potato gets played.
  • Documents proliferate like roaches – because of the relative ease of adding a new document to the methodology, without constant vigilance and refactoring it is easy to end up with too many document templates along with their supporting entourage of job aids and examples.
  • Redundant or conflicting information – documents supporting project delivery are moderately interdependent. Standalone documents usually replicate common information elements such as tombstone data and when a change gets made to one document template, the effort required to ensure consistency and alignment with all dependant document templates can be prohibitive.
  • They encourage an obsession on generating comprehensive documentation over delivering business value

But before jettisoning your documents in favor of a centralized tool, read next week’s article in which I’ll assess the pros and cons of that approach!

 

 

 

 

Categories: Project Management | Tags: , | 1 Comment

While collocation is nice-to-have, meeting in person should be mandatory!

Colocation is often considered an enabler if not a critical success factor for successful project delivery.

While this makes sense for small teams, as we take on larger scale products and projects, it is not always practical to have everyone in the same room. Communication channels increase non-linearly as the size of a team grows and at some point it will be impossible from either a real estate or an effectiveness perspective.

As the size of an initiative grows, breaking down scope along component or feature lines can enable the distribution of contained work to smaller teams whose members might be collocated with a reduced need for constant communication. Having such teams distributed geographically should not be an issue so long as there is still the opportunity to conduct ceremonies such as a Scrum of Scrums to manage interdependencies, maintain alignment in release cadence and to raise shared impediments to the right level of resolution.

With such a distributed approach it is often tempting to use a purely virtual work model, especially on large initiatives where there could be a heavy cost to bringing everyone together once in a while. While this makes short term economic sense, Simon Sinek’s warning from Leaders Eat Last should not be ignored: “The more abstract people become, the more capable we are of doing them harm.

Sinek references Milgram’s experiments in the early 1960’s where test subjects were given the opportunity to do harm to someone else. While only 30% of these volunteers were capable of proceeding substantially through the experiment when they had to witness the (simulated) pain they caused, 65% were capable of doing so when they never saw who they were hurting.

Our very current problem of cyberbullying is another shining example of this. While we are still biologically social animals, the anonymity and separation created by the Internet and social media platforms reduces personal impacts of inflicting pain.

Trust is also hard to cultivate when we haven’t met those we are working with. While we hope that our co-workers will treat us as they would like to be treated, it is hard to feel psychologically safe with them if they are just an e-mail address or instant messaging avatar to us. As Sinek puts it “Trust is like lubrication. It reduces friction and creates conditions much more conducive to performance.

We may have differences of opinion at work, but if we have met and had the occasion to socialize outside of the office, it is much easier to see and treat one another as human beings.

Economize as necessary, but don’t eliminate opportunities for teams to meet in person.

 

 

 

Categories: Project Management | Tags: , , | 2 Comments

All form and no (agile) substance?

Plus ça change, plus c’est la même chose

Jean-Baptiste Alphonse Karr’s warning reminds us that it is very easy to ignore the Manifesto for Agile Software Development’s value statements.

We might have done away with heavy project governance, premature or excessive planning, and documentation for documentation’s sake, but if we don’t remind ourselves why our team performs specific agile ceremonies, we are no better than our brethren toiling under the burden of traditional, one size fits all delivery practices.

Let’s start with sprints. Short time horizons should focus our efforts towards delivering value early and regularly while having fixed time boxes enables forecasting when we should be able to complete a release. But if we start treating sprints as phases (e.g. development, testing) or we batch work items within sprints in a waterfall manner, we haven’t really gained benefits from this approach. Similarly, if we don’t respect sprint end dates or we regularly modify the duration of our sprints we can’t forecast effectively.

How about your daily standups or scrums? These are meant to serve as micro-planning opportunities to align team members towards accomplishing sprint goals. They also provide an opportunity to surface blockers in a transparent, safe fashion to ensure these get resolved in an efficient and effective manner. But if team members are absent, we don’t start or end on time, one person monopolizes the discussion, or they turn into status meetings, why hold them at all?

Velocity enables teams to assess their throughput sprint over sprint. Used correctly and with the right underlying discipline on work sizing and backlog management, velocity can help a team forecast. But obsessing over velocity is as bad as focusing on percentage work complete in traditional approaches. When abused velocity leads to progressively reducing quality, erosion of team morale and unhealthy comparisons between team members or teams.

Showcases or demoes give a regular opportunity for key stakeholders to view what has been completed, to provide feedback to ensure that what is delivered meets customer needs, to maintain sponsor commitment and to provide a forum for visible recognition of the team’s hard work. But holding these ceremonies when there is nothing meaningful to demonstrate provides limited benefit to the invitees. Having the agile lead or other team member be the only person conducting the demoes doesn’t give everyone a chance to have their day of glory. And having team members get defensive when constructive feedback is provided about a feature which doesn’t quite hit the mark is just going to further the gap between the delivery team and the customer.

Meet the new boss, same as the old boss” – Pete Townshend

 

 

 

Categories: Agile, Process Peeves, Project Management | Tags: , | 2 Comments

Blog at WordPress.com.

%d bloggers like this: