Project Management

Articles related to doing projects right

Gantt charts still have a place in the agile-verse!

Those of you who have followed me for a while will know that I value pragmatism over absolutism when it comes to delivery practices, tools and techniques. Pick the right tool for the right job should be a guiding principle followed by all project teams.

Easier said than done!

It is difficult when enterprise standards dictate a fixed tool set, but it is even more challenging when a company is undergoing a fundamental transformation of its delivery practices. When adopting new delivery frameworks it is tempting to embrace the bright, shiny new tools while branding those of the previous delivery approach as obsolete, but if we understand the context in which their usage will still add value we should still find a home for them in our toolboxes.

A good example of this is the use of Gantt charts by teams who are following an adaptive or agile delivery life cycle.

Although Gantt charts have been around since the early 1900’s, just as with people, age is not negatively correlated to value. Tools such as burn-up charts provide an objective means of evaluating progress towards completing a release, but it is rare outside of pure product development contexts to find projects where a traditional representation of a schedule wouldn’t also provide some incremental benefits.

This need could arise from any of the following causes:

  • Complicated dependencies between the outputs from different teams
  • Work streams that are delivered using traditional, deterministic life cycles
  • Activities performed by supporting roles working outside of the agile teams

The project team will want to define the best way to combine the use of traditional and agile scheduling tools to avoid information duplication and inconsistency. Agile teams can continue to use their default tools, but traditional scheduling tools can be used to track other work which is not captured in the backlog yet still needs to be completed for project success. If there is a need to have an overall integrated project schedule, the agile teams’ sprints can be shown as a series of sequential fixed duration activities without the need to decompose those to any lower level. By reviewing burn-up charts, the exact number of such sequential activities can be adjusted to reflect accurate completion dates.

With significant change, there is a greater likelihood of success if you preserve valuable current practices when introducing new ones.

Advertisements
Categories: Agile, Facilitating Organization Change, Project Management | Tags: , , | Leave a comment

Does your PMO hinder or help your agile transformation?

An agile project management office might sound to some like an oxymoron, right?

This might be a reasonable assertion as many PMOs were first formed to provide oversight over a portfolio of projects and enforcing standards sounds like the antithesis to agility. But many successful PMOs have evolved beyond governance and control to helping their company reach higher levels of organizational project management maturity, and increasing agility should be complementary and not contradictory to this pursuit.

There are many ways in which PMOs can hamper progress towards greater agility including:

  • Enforcing standards over principles
  • Continuing to apply traditional funding models and prerequisites to agile investments
  • Obsessing over vanity metrics such as velocity or time to market rather than business value delivered or shipped features utilized
  • Evangelizing agile from the ivory tower instead of actively engaging with and supporting teams
  • Failing to inspect and adapt

So what can a PMO do to actively support an agile transformation?

  • Collecting chronic impediments from agile teams, curating and prioritizing them, and championing their elimination by the appropriate senior leaders
  • Having the courage to say “NO!” when a given context is not suitable for using an adaptive approach
  • Advocating for funding to incent early adopters to try new delivery approaches
  • Encouraging staff who possess the right expertise, behaviors and attitude to train and take on Agile Lead/Scrum Master or Product Owner roles with coaching support
  • Examining their own operational processes and leaning them out as much as possible
  • Shifting portfolio reporting from being a manual, onerous process to the automated consumption of information radiators
  • Migrating from an artifact-centric delivery approach to an information-centric model
  • Transforming heavy, gate-based governance to a metrics-driven, exception-based process
  • Working actively with functional managers, procurement, HR and other key stakeholders to change their project engagement models to be more support of adaptive approaches
  • Helping portfolio governance committees to make their investment selection, evaluation and prioritization processes more agile

An agile transformation provides the leadership of a PMO with a good opportunity to review their charter and service catalog – are these still relevant, and if not, what can be changed to ensure that the PMO is not identified as common impediment by agile teams!

 

 

 

 

 

 

Categories: Agile, Facilitating Organization Change, Project Management, Project Portfolio Management | Tags: , , , , | 2 Comments

What’s your project management personal best?

Outside of professional arenas, in sports such as weight-lifting, our competition is from within and not without.

Committed gym rats are keenly aware of how much weight they can lift, push or pull for each of the muscle groups in their workout rotation. Even though their overall goal might be to maintain their fitness level, they will try to add more weight.

So long as continuous improvement doesn’t become an obsession, this internal competition is healthy since it facilitates positive social interactions with our gym buddies as we all strive to help each other beat their own personal bests.

So can this concept also apply to project management?

Competing against other project managers is as futile as comparing our workout performance with another.

Just as there is always someone at your gym who is bigger, stronger or leaner than you, there are going to be project managers who will perform better than you do within a given context. While it is possible to reach a performance peak for specific hard skills such as scheduling or budgeting through a combination of education and experience, improving our competencies with soft skills and business knowledge knows no limits.

Our people managers will always need to assess us for annual evaluation or incentive purposes but with an almost infinite range of influencing variables which can affect project performance it will be very challenging to identify minor differences in competency. This is why subjectivity often drives decisions such as who gets the highest bonus in a team where everyone is performing well.

This doesn’t mean that we shouldn’t observe how other project managers are practicing their trade and identify and mimic the patterns which seem to bring them success. I might observe a fellow gym user who is using a different stance for a particular exercise than mine which seems to enable him to lift more weight than I can. I could give that stance a try if I think it will help but I need to remember that the stance which works for one person given their height, weight and skeletal and muscular structure might not be suitable for me.

The same model of work out machine will feel different when one goes from one gym to another. Each project is unique hence what causes someone to be successful on project A might result in mediocre outcomes on project B. Knowing that our personal bests are constrained by context, if we can isolate or reduce the number of variables, we can then establish a baseline against which we can measure improvements in performance. If we have had a trying relationship with a given group of stakeholders, on subsequent projects we can attempt to reduce the number of conflicts we have with them.

Do not let what you cannot do interfere with what you can do – John Wooden

 

 

Categories: Project Management | Tags: , | Leave a comment

Create a free website or blog at WordPress.com.

%d bloggers like this: