Easy in theory, difficult in practice

My musings on project portfolio and change management. I'm a firm believer that a pragmatic approach to organization change that addresses process & technology, but primarily, people will maximize chances for success. This blog will contain articles which I've previously written and published as well as new content.

About this Blog


Recent Posts

What do I look for when reviewing resumes for project manager positions?

RBS is one more technique for your estimation tool belt!

Technical Competency for Project Managers – Valuable Asset or Source of Risk?

The Achilles Heel of project resource estimation is operational work

A self-managing team does not mean no rules!

RBS is one more technique for your estimation tool belt!

Categories: Agile, Project Management

Project managers need to be comfortable with different estimation techniques. Foundational project management courses will teach you about analogous, bottom-up, parametric and three-point estimating. Take a course covering agile delivery and you'll learn about relative sizing techniques such as estimating poker or t-shirt sizing.

But have you heard of RBS?

I'm not referring to a Risk Breakdown Structure, a Resource Breakdown Structure (seriously, couldn't they have found a different name for one or the other to avoid creating confusion about which RBS is being referred to?) or any other type of breakdown structure, but rather Randomized Branch Sampling.

This technique was originally proposed by Raymond Jessen in 1955 for the agriculture industry as a method of estimating how much fruit would be found on a given tree (hence the significance of the word "branch"). This approach has been adapted by Dimitar Bakardzhiev for use on software projects following an agile delivery approach and could be similarly adapted for a traditional, deterministic project where a WBS has been created.

I would encourage my blog followers to read Dimitar's article but here is an overview of the process once you have decomposed your project to an appropriate level of details (e.g. epics & stories or control accounts & work packages).

  1. Make a note of how many epics or control account have been identified. Let's call this "M".
  2. Randomly pick one of the epics or control accounts.
  3. Make a note of how many stories or work packages are associated with that epic or control account. Let's call this "N".
  4. Randomly select one of those stories or work packages.
  5. Estimate the size or effort of that story or work package. Let's call this "X".
  6. Calculate the overall size or effort of the project or release using the formula X/(1/M * 1/N)
  7. Do steps 2-6 between 7 to a dozen times. This will provide you with a probability distribution for your project's total size or effort as well as an average or mean which you could use for your estimate.

This approach does require that your project is large enough to have at least a dozen epics or control accounts and does assume that the decomposition is clear and complete.

While you might be comfortable with tried and true estimation methods it's a good idea to use more than one estimating method. Certain techniques are appropriate at specific points in time over the life of your project based on stakeholder needs and the level of uncertainty remaining. There's also the benefit of being able to sanity check estimates when multiple approaches get used.

Learning new techniques such as RBS can help us become more effective project managers but only if we understand when and how to use them as well as their limits.

"A Fool with a Tool is still a Fool"


Posted on: February 18, 2018 07:54 AM | Permalink | Comments (9)

A self-managing team does not mean no rules!

One of the more prevalent myths with agile delivery approaches is that the project manager should let the team develop their own working practices and rules of engagement to manage themselves.  While this sounds great in theory, in many cases it will result in disaster.

No question, in times of crisis over usually fairly short durations a team of professionals can develop creative ways to work together effectively and productively to resolve the situation but this doesn’t translate well into the world of most projects where the sense of urgency or shared goal is usually insufficient by itself to encourage productivity and efficiency.  While testing this hypothesis might make for a good social experiment and has been utilized regularly on reality TV shows such as The Apprentice, few organizations will want to take chances with their critical projects.

I’m not advocating the anachronistic use of rigid command and control practices on the part of the project manager.  While a lack of attention and guidance to work practices and results may result in chaos, being a slave driver is almost guaranteed to cause project failure along with permanently damaged relationships between the project manager and team members.

As with other project management situations, this becomes a balance between the “what” and the “how”.

The project manager needs to ensure that the team had a clear, consistent understanding of “what” the expected project outcomes and benefits are as well as “what” the key deliverables and activities are.  The project manager also should set expectations and require compliance with “what” he or she needs to develop plans and to track and report on progress for the project.

However, when it comes to “how” the work gets done and “how” progress reporting and other normal practices will be performed, the project manager should provide the team with the flexibility to explore and develop the most efficient method for them.  This doesn’t mean starting with a blank slate or letting the team radically change directions on a weekly basis.  It does mean reviewing the organization’s standard or de facto practices at the start of the project and educating the team on why these practices are important and then giving the team the opportunity to adapt these practices and to regularly review them during retrospectives.

Moving to a more “black box” approach to work management provides greater empowerment of team members without the risks implicit with totally abdicating management responsibility.

(Note: this article was originally written and published by me in June 2013 on my personal blog, kbondale.wordpress.com)

Posted on: February 15, 2018 05:59 AM | Permalink | Comments (12)

Do you deliver dazzling demos?

Categories: Agile, Project Management

Demos, reviews or showcases as they are sometimes called, are a critical ceremony when they are run effectively as they address multiple project delivery objectives in a single event including:

  • Validating that what the team has completed to date is valuable from the perspective of their customer and other key stakeholders
  • Helping the team and stakeholders change or evolve their understanding of the desired solution
  • Getting signoff on completed work items in those organizations where such signoff is a required prerequisite for implementing change
  • Facilitating transparent progress reporting as stakeholders see what was committed by the team and what was completed
  • Providing team members with regular feedback and recognition for their hard work which increases levels of engagement and job satisfaction

But demos are just like any other project delivery practice in that their misuse could result in a worse outcome than if they had been skipped entirely. Here are some do’s and don’ts to help increase the value your organization gets out of demos.

  • DO send meeting invitations well in advance and if you are following a standard sprint or iteration frequency (e.g. two or three weeks) then schedule a set of recurring invitations
  • DON’T book demos on Friday afternoons to avoid having stakeholders who are absent in body or mind
  • DO share the wealth by having everyone on the team take a turn to present a demo
  • DON’T use the demo as your soapbox for complaining about the team, blockers or what could or should have been done different
  • DO provide objective context when sharing sprint or iteration outcomes (e.g. committed vs. completed)
  • DON’T present a demo without having tested what you are going to show beforehand
  • DO invite both your customer representatives and relevant control partners to your demos
  • DON’T overwhelm your stakeholders with content
  • DO record the presentations either in advance or (if you feel lucky!) during the demo itself for the benefit of any stakeholders who were unable to attend
  • DON’T take negative feedback personally

While this article is applicable for teams who are using an agile delivery approach, it is equally suitable for traditional projects.

Dazzling demos will help sustain the attention and support from your customer and will focus your team members on value delivery.

(Note: this article was originally written and published by me in January 2017 on my personal blog, kbondale.wordpress.com)

Posted on: February 14, 2018 08:29 AM | Permalink | Comments (12)

Maintain a sense of change urgency through agility

Categories: Agile, Project Management

According to John Kotter's model for leading change, the first step to overcoming inertia requires us to instill a sense of true urgency in those we need to support, implement and sustain the change. While it is ideal if this urgency is tied to What's In It For Me, at a minimum, we all want proof that committing our time and political influence to a particular initiative at this very moment is cheaper than the cost of doing nothing.

But the steps in Kotter's model, like PMBOK processes, are not to be followed in a purely sequential manner.

Significant organization transformations usually require a year or more to become "the new normal" and we are only fooling ourselves if we assume that those stakeholders who were focused and motivated to champion our initiative in its early days will continue to remain so for the long haul. Executives and mid-level managers are constantly juggling competing priorities and as long as it appears that a change initiative is not on fire, their attention spans are likely to be shorter than that of a goldfish.

As such, we need to iterate back to instilling that sense of true urgency at regular intervals. The specific cadence varies based on the complexity and duration of a transformation. Fan the flames too rarely and the spark will be extinguished. Do it too often and you'll be treated like the boy who cried "Wolf!".

But is reminding stakeholders that they need to support us enough to gain this support? Maintaining focus requires quid pro quo otherwise we are likely to hear "What have you done for me lately?"

This is why regardless of the nature of a transformation we need to inject agility into its delivery. We can follow adapted versions of key Manifesto principles such as:

  • Our highest priority is to satisfy our stakeholders through early and continuous delivery of business value
  • Deliver business value frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale
  • At regular intervals, the team reflects on how to implement change more effectively, then tunes and adjusts its behavior accordingly
  • Change champions and the team must work together frequently throughout the transformation

Newton's first law: An object at rest remains at rest, or if in motion, remains in motion at a constant velocity unless acted on by a net external force.

Posted on: February 04, 2018 10:32 AM | Permalink | Comments (12)

All form and no (agile) substance?

Categories: Agile

“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 (Sante - that's a 70's reference, just for you!)

(Note: this article was originally written and published by me in May 2017 on my personal blog kbondale.wordpress.com)

Posted on: January 31, 2018 08:32 AM | Permalink | Comments (10)

"He who asks is a fool for five minutes, but he who does not ask remains a fool forever."

- Chinese Proverb