Project Management

Facilities Management

Agile Project Management-Managing the Job

Last week, the topic of my blog post was an introduction to Agile Project Management, where I introduced the idea of duality between managing the “Job” and managing the “Work”.  Today, I’d like to look a little closer at the Job to examine the key distinctions that differentiate the two and how this aspect can take on a life of its own.

In a pure sense, the Job should be a small case version of a portfolio consisting of several work package elements.  The Project Manager (PM) fulfills the role of Task Master guiding the larger team, individually driven by Leads and Scrum Masters, towards a common goal.  Using a locomotive analogy, the project is a train consisting of a string of connected cars on the same track (ideally) heading to the same destination (a common goal).  The PM must effectively keep the train on schedule and on budget notwithstanding a few new cars and a couple of extra pick up’s (features) being added along the way.

The Job is always and only viewed through the lens of cost and time on a linear scale.  The belief is that all aspects of the project abide by these metrics; therefore the Work simply falls out (or feeds on) each of these two buckets (money and time).  This fact is the first of a potential series of collective fatal cuts that can cripple a project.  This view of the world makes the project about money and about time as if these completely describe the deliverables.  If the “plan” is reduced to this, then this underpins why plans are useless on the battle field. If money is a deliverable, and adding a feature will deliver more money, then we’d be silly not to do it….right?  Adding another car to the train isn’t as simple as stopping, hooking up, and hitting the gas pedal to get back up to speed.

The regular cadence of Job management aligns with regular senior management and customer reporting.  Here, the PM rationalizes the team performance using metrics based upon monetized work elements for the purpose of assessing earned value.  The PM processes these numbers as a bottom up conveyance of the Work in a way that makes sense to an audience that measures value in a different way than the team doing the work.  While the team is busy executing against the work plan, the key stakeholders are involved in other ventures on behalf of the corporation, market, customer ventures, etc.  Changes in these external events can and do influence the project, often without regard of the general health of the project commitments.  If we reverse the cause and effect relationship, changes in cash or cash flow (caused by some external event) may not be understood to have an impact on the work.  An example of this would be a resource group departmental drive to hit a cost reduction target for a given reporting fiscal quarter so that the high ranking manager can get a bonus.  In order to do this, all you’re being asked to do is rearrange your cash flow for the next couple of months until the new fiscal quarter.  This shouldn’t affect the work….should it??  Sure…if we don’t look at the tracked actuals… no problem.  Oh yes… and by the way the deliverables will stay on track to our customer expectations.

I suppose climbing the corporate ladder somehow impairs logical sensibility.  These types of occurrences are commonplace and must be navigated by the PM.  In order to keep this in check, the PM must be diligent in maintaining project requirements, risks, stakeholder expectations, and ensuing change orders because these aspects of the work are reasonably easy to convey in business speak.  The PM can successfully protect the project from these perils by way of effective communications that resonate with this particular audience.  Attempts to show burn down charts and cumulative flow diagrams will only result in the same indigestion as would earned value metrics to the team doing the work.


Agile Project Management

Agile framework work flow is a mature methodology for organizing teams, the efforts of the members, and the collaboration of the members.  In certain industry circles, this method is commonplace, but is usually isolated to select functional departments within a corporate structure.  Software development departments by far are the most prevalent Agile centered teams, such to the extent that fresh graduates entering the full time workforce are “Agile ready” right from the get-go.  This is the case due to work term experience, but as a case in point it demonstrates the need for a Project Manager to understand this powerful methodology in order to get the very best from their team.

The key distinction for a Project Manager is to differentiate between “getting the Job done” and “getting the Work done”.  The Job and the Work are obviously associated, but are two very different things when it comes to Project Management. The Job is the bigger picture aspect of a project team’s day to day activities.  The Job must be focused on the goals, statement of work, requirements, stakeholder expectations, risks, opportunities, finances, and key milestones.  These are all part of what I call the linear timeline.  The timeline can be pre-planned and effectively managed applying a waterfall methodology.  The Work is dynamic which simply is a misfit into the timeline management model.  The Project Manager must be very aware of this and be effective in keeping the two worlds running on the same path.  Please check out my blog posts on blending waterfall and agile.

An effective Agile Project Manager does not have to be a Scrum Master, but does have to embrace the operating mode and ensure that the agile team is always sprinting towards the goal posts set by the linear timeline.  In small organizations, it can be difficult to separate the pure technical management roll, so sometimes the PM has to wear many hats.  None the less, I just want to make the point that an Agile PM doesn’t have to be a Scrum Master to be effective.

Agile framework dynamic work flow visualization is very different than linear waterfall visualization.  From a toolbox aspect, I have found that JIRA is the best platform that I have used.  Whether the team is co-located or global, JIRA provides a great adaptive environment to structure, collaborate, and provide metrics that are meaningful to the team getting the work done.

Stage-Gate Workflow Model


The Waterloo regional Project Management Institute (PMI) meets monthly in our Peer-to-Peer P2P PM Connect group.  As a co-Champion, the organization of monthly topics as well as the content and presentation forms part of the Champion roles and responsibilities.  In keeping with this expectation, I presented at our March 2016 seminar how to introduce new management philosophies.

I first encountered Stage-Gate® work flow management by way of reading published material authored by Dr. Robert G. Cooper.  I have included these references in the bibliography slide in the presentation deck.  I had originally read the material on or about 2003 driven by a growing desire to better understand the inner workings of the methods and processes for getting work done.  I was at approximately the 18 year mark in terms of on the job engineering experience in design and project engineering management; yet, I had never encountered a process system that even attempted to emulate the Stage-Gate system.  This is not to say that I hadn’t experienced a structured work environment.  I experienced structured stages of activity and periodic reviews, but the expectations were never made known early enough to have any real hope of achieving the intent.  It was as if the reviewers purposefully sprung their expectations on the execution team at the last minute to exercise an air of supremacy and control.  It also seemed to me that some managers sought to prove that the organization had failed them such to the tune that their departmental shortcoming was the product of inadequacies in the team; not their personal performance.  A clear redirection of blame.

So…you’d think that if the team failed the review, then management would have taken action…right?  Nope….the team just kept on working until the next review.  More and more, what I found was that a failed review was handled by management as an orchestrated slow death by starvation.  Team members would progressively get re-assigned, purchase orders would not be executed, and so on until the job just fizzled out.  There was no sign of a clear decision to go, stop, or re-work.  To this day, I have yet to witness a project that was decisively stopped when it needed to be killed.

I was certainly converted by what Dr. Cooper had developed, and proceeded to promote Stage-Gate in the various roles that I have held over the past 13 years.  My approach was to set progressive and incremental expectations so that targets in the early stages recognized the “end game”, but were initially relaxed in the early gate reviews.  This would do two things, (1) ensure early recognition of stakeholder expectations and (2) make it possible for the team to incrementally work to the final expectation.  As an example, if the product build cost at production launch was expected to be $1,000.00, then the concept stage would be considered on track if it was within an agreed margin of the extrapolated cost.

In almost all cases, the initiative was met with resistance from management stating that structured work flow and gates are intrusive to creativity and impediments to serving the customer. In some cases, the corporate organization didn’t have a documented work flow; in other cases a generalized work flow was established, but no gating criteria was set.  In both cases the primary roadblock was setting the gate expectations prior to the start of work execution leading to the gate.  In short, the gate committee comprising of management would not contribute expectations in advance of the gate review.

This presentation provides a bit of background of Stage-Gate, and introduces structuring, a basic model, and a process to customize the model to suit a corporate mode of product or service introduction.  Having this workflow wrapper developed, the corporate projects currently in work can be seamlessly integrated into the Stage-Gate workflow model.

Please have a read of the attached presentation package.  I’d love to hear your thoughts and any stories you would like to share on the subject.

How to Introduce New Management Philosophies

How to Introduce New Management Philosophies – R0

The Waterloo regional Project Management Institute (PMI) meets monthly in our Peer-to-Peer P2P PM Connect group.  As a co-Champion, the organization of monthly topics as well as the content and presentation forms part of the Champion roles and responsibilities.  In keeping with this expectation, I presented at our March 2016 seminar how to introduce new management philosophies.

The presentation of this “How To” topic was organized as an interactive session as opposed the typical uni-directional delivery of information between a presenter and the audience.  The intended “take away” from the session was to (1) learn how to organize a collaborative approach to the introduction of a new philosophy or process, (2) to involve the right people, and (3) recognize that there are differences in the way people deal with change

This seminar was attended by approximately 36 members.  The seminar was 1 hour in total duration, which was generally partitioned as follows:

  1. General Introduction
  2. Choice of new philosophy topic to organize the “how to”
  3. Structure Audience participation
  4. Participative Session
  5. Q & A

Now…an hour is not a lot of time, so the seminar needed to be fairly concise in order to complete the five part agenda.  It was important to allot ~ 30 minutes to the participative session in order not to rush or stifle the participants.  The structure of audience participation was predetermined.  It was important to ensure that the session had a high participation rate, and that the selected topic of debate was something that resonated with the participants.  I had a fairly good idea that the general turn out would be in the 30 to 40 attendees; so I knew that contributions would be improved greatly by dividing the audience into smaller teams.  We ended up with 6 teams.

The topic of discussion really needed to be something that came from the audience; therefore, the topic could not be predetermined.  This aspect of the presentation could have derailed the entire seminar, but fortunately we were able to quickly converge on a topic that the audience was excited about.  The topic was:

How to Introduce a more Structured Project Management Philosophy without constraining individual Group Operations”

This was an excellent topic because it dealt with the very root of the adversity that usually results when anything new is introduced.  To further elaborate on the aspect of adversity, I presented a simple character type model developed by Dr. Paul Stoltz.

The predetermined participation structure was a team brainstorming session where all inputs are categorized as follows:

  1. Problem Statements
  2. Potential Solutions
  3. Known Barriers
  4. Action Plans

The teams were given 30 minutes to verbalize and document their inputs.  This worked out very well and reinforced that a collaborative brainstorming session only requires approximately a half hour if set up correctly.

The attached presentation captures the agenda items as well as a collation and analysis of the collected inputs from the 6 independent teams.  You will note when reviewing the conflicting statements that at least one team elected to avoid a particular topic while at least one other team chose an authoritarian course of action.

Based upon feedback that I received, the seminar was very successful.  It was a live brainstorming session that produced concentrated voluntary input from 36 individuals in the space of 30 minutes.  It also showed that there can be very different views and opinions regarding how to handle behavioral differences.  Whether the team differences were truly collaborative or perhaps coerced is beyond the scope of this discussion.

Visual Management Toolbox

PM Connect Visual Toolbox Presentation

The Waterloo regional Project Management Institute (PMI) meets monthly in our Peer-to-Peer P2P PM Connect group.  As a co-Champion, the organization of monthly topics as well as the content and presentation forms part of the Champion roles and responsibilities.  In keeping with this expectation, I presented at our February 2016 seminar a Visual Management Toolbox…. a few important tools that you should know about.

The topic subject of Visual Management was presented in a 3 part seminar; this being part 2.  The theme of that segment was visual management, where the trilogy sub-topics were:

  1. Visual Project Management
  2. Visual Management Toolbox
  3. How to Introduce New Management Philosophies

From a theme prospective, the objective for any and all project managers is to convey key information and messages in a concise and digestible form.  Visual management goes beyond the simple use of visual aids by way of transforming the data into a graphic format that can be rapidly absorbed and understood.  From a toolbox prospective, this presentation aims to introduce and demonstrate a few examples where detailed data can be handily reduced to a clear and concise visual.

For this presentation, four commonly available tools were showcased:

  1. Mind Mapping (The Brain)
  2. Gantt Scheduling (Microsoft Project)
  3. Workflow Management (JIRA)
  4. Collaboration (SharePoint)

From an applications standpoint, four common work space/activities were used as examples:

  1. Brainstorming
  2. Presentation Dashboard preparation
  3. Team planning and daily organization
  4. General work space management

The attached slide deck presents a representation of these applications in the showcased tool.  In keeping with the visual theme, the primary goal of each application glimpse is to demonstrate how a visual portrayal can enhance organizational structure of the data making it easier to understand; and in some cases add a dimension of association that otherwise may not have been apparent.  Pay particular attention to the mind mapping example in terms of multi-dimensional modeling.

Application topics (2) and (3) deal with the age old organizational chasm that divides the business unit from the project team executing the work.  Waterfall (gantt representation) and Agile framework management are often considered incompatible resulting in opposing camps in many organizations.  This very topic is the subject of an earlier blog post.  This presentation demonstrates that both Waterfall and Agile framework are necessary, and that each have inherent strengths that are essential in building a clear and concise visualization in project status reviews.

The final application topic deals with work space management.  As a general model, the work space needs to be segmented to provide for the following groups:

  1. The General Audience
  2. The Stakeholders
  3. The Team

For the purpose of this presentation, a Microsoft SharePoint model was created to provide guarded access to all individuals that would require and/or desire some level of access to the project.  This provides protected environments where sensitive information can be freely shared within a group, and made readily available only to that group.  In my experience, many organizations over utilize email and seriously under utilize SharePoint as a key collaboration tool.

I hope you enjoy and take away some new ideas and knowledge from the attached presentation slide deck.  Please send any feedback that you have.

Blending Waterfall and Agile Presentation

Blending Waterfall and Agile

In my role as Champion at our local Communitech PMI Chapter, I jointly planned our 2015 / 2016 season seminar topic series with my two co-Champ compadres.  The topic of blending Waterfall and Agile was the logical kick-off point given it addresses the needs of the holistic enterprise.  The follow up 8 presentations comprising our annual seminar series focused on visual management, corporate cultural change, work flow modelling, and stakeholder management.

There is a fair bit of momentum within the corporate culture at many organizations to adopt agility and lean practices  as they frantically strive to remain competitive.  This pursuit affects both large and small; mature and startup companies alike.  More often than not, what I experience is an emphatic disdain for the Waterfall planning and management model; hence, the immediate reaction is to completely replace it with an Agile framework.  I have also observed that the Agile model is perceived to eliminate the overbearing and wasteful planning allowing the team to get onto the “real” work sooner.

To quote Dwight Eisenhower “In preparing for battle, I have always found that plans are useless, but planning is indispensable”.  So…to translate into Job Speak, the sequential waterfall plan is not a view of the battle; its the map of how to win the war.  Last check….maps are still King!

I have attached the slide deck I prepared and presented at our chapter monthly seminar in October 2015.  In looking at the pursuit of a product or service delivery, from a holistic point of view, there are three corporate players each having their key indicators that underpin the mantra of their existence.   Of the key indicators, I have identified the critical indicators.  The central focus of this presentation is to align indicators to each of the Waterfall and Agile framework models to establish a best fit.

Please have a read through of the preso. I’d love to hear your feedback

Blending Waterfall & Agile… a Dual Method Culture

The ongoing debate between the Waterfall Campers and the Agile Camper’s should had never began as an either/or battle of righteousness. The Waterfall/Agile dual method culture is a management model I’ve been advocating for some time, but I’ll admit the audience remains largely split on the subject. I’m happy to report there are others out there who are of the dual culture mindset. I came across an article on this very subject. It is like a breath of relief that there are others out there that understand that it is not a competition between waterfall methodologies and Agile Framework. This is the very paradigm I have focused my Project Management methodology approach upon. I would like to take this opportunity to steer these presented thoughts a little further down the path to successful implementation. The article that I’m referring to can be found at this link:


Topic #1- How Difficult is it to make a change?


Change, in my opinion, is not difficult…it is uncomfortable. I’d argue that change is actually quite simple. It’s staying on course to the end goal is the tough part. Now perhaps I mincing terms here, but I strongly believe it is important to distinguish the difference between change and staying on course. Change is instantaneous like flipping a switch. Flipping that switch is that critical point between stimulus and response that sets you back into the correct direction.


Any change in process must be incremental in almost all working environments assuming that the business is currently engaged in critical path work to serve the customer. I’m not insinuating a partial change, but rather a staged change beginning with a designated team who can adopt a change in process without crippling the active project currently in workflow. An ideal opportunity would be a mature team in a reasonably stable stage of a project where minimal disruption would result.


Question….what are we actually going to change?


What is changing is the way we visualize and measure the work. For simplicity, let’s assume that we’re instigating change to a project currently running the company’s legacy process for their project monitor and control. For this example, we’ll consider changing a classic end-to-end waterfall methodology. Keep in mind, a similar situation can also consider change in the other direction (i.e. end-to-end Agile transition to Waterfall). The first thing to understand, is that the corporate and project team work flow is not affected by change in monitor, control, and visualization of the work in progress. It is also important to understand that the choice of methodology does not set the work flow. Work Flow is set independent of the methodology.


The corporate work flow models that are linear are best suited to Waterfall methodology. The non-linear work flow models (i.e. highly dynamic) are best suited to Agile Framework management. It is not a contest, but rather a choice of which methodology to apply to which work flow.


Topic #2- How quickly can you expect to see a measureable success?


In order to quantitatively measure the impact and affect, you need to have established a clear expectation, and a clear set of metrics to make a comparison. For our example, moving a dynamic work flow to an Agile framework will produce an immediate benefit to the project team doing the work. An agile framework is far superior at the “hands on day-to-day” level of work. The team decides what needs to be done, and collaborates on getting it done. This fact must be communicated because the power that results from taking back control is extremely liberating. On that note, it is important to include soft measureable metrics such as workplace satisfaction. Early stage improvement in the work environment will produce significant quantified metrics down the road.


Topic #3- How do we report the metrics gathered from Agile into our Waterfall Earned Value?


This is ultimately a challenge of currency conversion assuming that the Agile work planning is structured. A structured Agile work plan would have clearly defined tasks in the backlog queue, each with an estimate for effort in measured in hours. Each task would produce a tangible artifact as a deliverable. I’ve seen esoteric Agile metrics like models of Ford Trucks and Farm Animals to size tasks which will not be translatable to anyone outside the closely held team. It is important to maintain continuity between the linear and dynamic methodologies. One version or another of a burn down chart translates into a ratio for % Complete and % Physical Work Complete. Metrics can be merged if handled correctly.


In conclusion, I’d like to leave you with this visualization. A project is a horse race with a clear start and a clear finish. Agile deals with the jockey and the horse; Waterfall deals with the race track. Both methodologies are needed for a race to occur, and both need to be managed.