Dave Kean

As a PM here is what I believe

I believe in…

• The church of the Project Charter
• Defined deliverables
• Listening to the experts
• Small teams with big white boards
• Understanding where value is added by the process
• Old fashioned, but effective to-do lists
• Pain is there to remind you what you did wrong next time you try it
• Post-it notes, many, many post-its in different colours
• Having the right numbers is some times less important than having the same numbers as your boss
• Recognizing everyone who makes a contribution
• Talking to the experts who understand the product
• Never betting against Microsoft
• Define then execute works best
• A bulletproof change management process
• Leaving the exec’s wanting more
• TPS works because of the people
• Speaking plainly, clearly and as a team
• Short presentations
• Sharing the credit
• Hardware guys will blame the software
• Software guys will blame the hardware
• That there is no such thing as perfect code or hardware design
• Visibility can be both good and bad, managing it is important

Before today I knew a little about agile project management. It’s not a new model, especially if you’ve been involved in software development. On the surface it looks like another form of incremental and iterative development, but it’s actually a little more than that. It’s certainly got some interesting ideas that on first glance look like they will transition to the hardware manager role.

I’m in the process of developing a couple of complex tracking tools that if it goes well will allow me to lean out my job and automate a couple of the more time consuming functions. The idea has a lot of potential, but will blow up the way things have been done for a while and start over again. Not always a popular more.

My proposal involves a lot of process changes in addition to the development of the tools. It’s a huge project and I’ve been given some resources and buy in to create a pilot over the next couple of months. One of the aspects of agile that separates it from regular incremental/iterative spiral PM is the speed of the release cycle and role of managers in enabling the rapid turns.

One of the issues I’ve come across outside of my home org is managers that have vast experience and knowledge of the product, I don’t mean to be disrespectful, but they are really the very definition of “anti-agile”.  They don’t so much just coach people, as direct them. As a result, the people are not empowered to do what’s needed and with that comes a certain level of frustration from those in the trenches. The managers are not doing management work.

In my org Managers may have lived with the product for a long time, but have never lost focus of who is in the offices and cubes everyday dealing with the issues close up. I think they have done a good job of getting the right people and putting where they are needed. Let people do their best and lead out teams and we will move heaven and hell to deliver a good product. I’ve yet to have my actions second-guessed in this org, and that’s quite the testament to my managers and the freedom they give the leads.

I spent a little time today talking about “agile PM” today with an experienced practitioner, it’s gained quite a lot of exposure in the PM world recently. As I’m getting back into that role figured I should learn a little more about it. Some of the idea fit rather well with my proposal. I’ve got to pitch it next week to the peer review group, which is always a tough audience. Once I’m through that and my idea is not totally shredded, I get to rebuild and present it to the program managers. That’s not as hard, but way more nerve racking.

Back to agile, as I said it’s got some very interesting concepts, especially on the difference between iterative and incremental releases that at first glance look like they will apply rather well to hardware and configuration control.

It seems that an important aspect of lean is the role of managers. They are there to support and empower, rather than direct, from what I got today managers have a couple of major tasks in agile.

First as program managers whose main responsibility is to directing a multi-project portfolio in their org. They are interested in more than a straight cost/benefit business case; they also want me to show where we will leverage the work into complementary projects in the future.

Second is creating an environment for success. This can mean ensuring resources are available, of making sure the minutia of day-to-day in a big org are taken care of and finally running interference with other groups. My group is lucky we have someone who takes care of the minutia part rather efficiently, but seemingly trivial things like signing up for training or booking travel takes significant chunks of time. The final part, running interference and allowing us to concentrate on the projects is becoming more and more important, and I work for a manager who is very good at it.

I’ve got some reading to do when I get some quiet time next week, probably while sitting on an airplane.

At work we use Earned Value to track our projects, not the most straightforward way to do it, but one that seems to add a lot of value for the work done.

I like EV, but it does become a little bit of an acronym hell. This is in a business world already overpopulated by PowerPoint’s bearing total gibberish.

EV has a number of issues in actual use. First it tends to be a little complex for the one-slide leaders who like simple stop light charts. There is no chance of having the time, or my boss having the attention span to talk 10 or 12 different EV metrics.

So if I have to choose one or two EV metrics to talk when reporting out to those with the attention span of a Golden Lab at a Frisbee factory, what am I going to use?

A bigger, and perhaps the biggest problem is that the project has to be fully understood and defined. And in a world where bigger projects full of go/no go gates and smaller projects is a little more ad-hock this is becoming difficult to do.

Scope creep destroys the whole basis of EV and makes it meaningless. The baseline must be complete, understood and adhered too. Deviation, creep, rescoping means re-baselining and what I see as probably the most important EV metric, Cost Performance Index (CPI) utterly meaningless.

This brings me to today’s discussion in cubeville that was started by a college project I’m working on.

First we pulled out our PMBOK’s and spent a little time reviewing all the EV metrics. I think we all agreed that first is Cost Performance Index (CPI) is the first we should follow.

CPI is a straightforward; it compares the work actually done to the actual costs of getting that work done. What have we completed, compared to what we have spent.

When CPI=100% for every hour we’ve spent on the project we’ve earned one hour of value.

It’s a snapshot of where we are today. If the actuals are correct (hours, cash, widgets delivered) and the project baseline accurate then CPI gives a good idea how close you are to budget or projections you are. It’s simple and the results are clear.

Last week at the BTEC there was a paper presented that stated that once you got to 20% of project completion, performance to date becomes an accurate indicator of future performance.

It was based on the analysis of a number of Department of Defense contracts and the data showed that once you got to 20% of the way through your project, you could accurately predict the final results to within 10%.

If you were to divide total budget (BAC) by the CPI at 20% project completion, you should be with in 10% of the final cost.

So if you were on time/budget at 20% completion, you would close to budget at project completion.

However if you were at 25% of budget at 20% completion you would end up at somewhere around 125% (+-10%) at project completion.

This potentially a huge “early warning” that a project is in trouble. However you’ve spent the money and CPI shows what we’ve got for that expense. What do we have to do to get back on track?

That’s where my second EV metric comes into this. To-complete Performance Index (TCPI). TCPI shows how efficient we have to be to finish the project on time/budget with where we are today.

TCPI is another simple one it’s “work remaining/funds remaining”.

If the project is behind or over budget and TCPI needs to be moved back to 100% there are two ways to do this. Rescope and reduce the amount of work, or increase the budget to compensate.

It is not uncommon for projects large and small to go over budget and when making a new forecast it’s easy to assume that everything will suddenly go right, that problems are behind us and from here on it’s all going to be OK.

Once the TCPI shows that the budget is no not realistic for the work remaining the first question from leadership should be how much money will it cost to complete the project. The risk at this point is that another unrealistic budget is completed, and every month it’s revisited and matched to actual performance with out ever understanding what was wrong with the initial estimate.

This revising makes the whole point of tracking EV pointless as the metric is not being tracked to the original baseline.

I have just finished reading “The Black Swan” by Nassim Nicholas Taleb. Black swan theory is used to explain rare, high impact events that were difficult to predict and leave some notable or significant legacy.

The term “black swan” comes from the European conviction that all swans were white, and all historical data available backed this theory and therefore black swans did not exist. During the 18^th century black feathered swans were discovered in Western Australia, since then the term “black swan” was widely used to denote something that is thought or perceived to be impossible, but none the less happens.

Taleb gives World War 1, the internet, personal computers and the 9/11 attacks as all examples of Black Swan events that have three things in common. Later articles by Taleb (HBR 10/09) include the mortgage meltdown of 08/09 in this list.

First, they were outliers. Each of these events were so far beyond expectations that their very occurrence came as a surprise as there was nothing that pointed to what was coming.

Secondly, the event has an extensive and far had reaching impact.

Third, even though we did not see it coming, we can go back after the event and create a plausible trail of evidence that points to what was going to happen.

This third part is for me particularly interesting. Upon reflection we could see a trail that could lead one to understand that the Black Swan event was coming and do something about it before the full seriousness was realized.

These very low probability, but very high impact events are by definition almost impossible to predict and very difficult to see coming. Traditional risk management largely depends on past experience to predict the future, but this model breaks down totally when there is nothing to compare with.

When a project team starts working on a product introduction into the factory we are tasked with identifying risks and mitigating those risks to reduce both likelihood and impact. We use the experience of each team member to identify, quantify and understand the risk and create a plan to reduce its effects.

Occasionally we get something out of nowhere (a Black Swan event) that no one has seen before that causes the extensive and far reaching impact Taleb talks of.

During and aircraft interior fit at a customer it was discovered that the conversion of some Computer Aided Design (CAD) models from one software system to another had led to the “envelope” of the models to shrink by 10%. This caused the physical and digital mock ups to be incorrect and when the vendor supplied parts that were built to the incorrectly converted models were installed in production nothing fitted and there were substantial gaps between the side and the furnishings.

There was nothing in the teams’ experience that had even suggested this could happen. This was a Black Swan event that caused a six month delay of the aircraft back into service and a knock on that caused the entire retrofit program to be delayed, which in turn had a knock on effect on as the new build became concurrent with the retrofit program instead of following.

Taleb states that with the ever increasing tangles webs of relationships and interdependent actions (in this case vendors, customers, regulatory authorities and three or four internal organizations) that Black Swan events are becoming more and more likely, as an outlier event in just one of these places means a huge impact to the rest.

For me, probably the most important lesson from the book is that it’s better to reduce vulnerability to low-probability/high impact events, rather than trying to anticipate then events themselves. While experience and past lessons learned can help many risks, the true Black Swan events mean that it’s not about controlling what may happen, but to prepare for what can.

It’s that time of year when I need to buy my planner refill for next year, for the last couple of years I’ve been using Franklin Covey to help organize my work-flow. Generally I like the system, but the lists can become a little difficult to manage. In short it’s a top-down/pull planning system that does its initial sort by importance and is weak when it comes to urgency.

When stuff percolates to the top of the list there is no time context in the FC system. There seems to be a bunch of low priority stuff that never makes it to the top of the list and stays there for months. It requires a both time and a little discipline to look down the list and deal with small stuff before it comes bigger, and FC does not seem to be conducive to that.

I picked up David Allen’s widely known book “Getting things done” (GTD). I’ve worked with a few devotes to Allen’s system in the past, but have never read it or thought too deeply about it, after all FC worked just fine, even if it became a little unwieldy after a while.

The start of GTD is collecting everything that needs to be done in a bucket. It does not matter what that bucket is, email inbox or notebook both seem to work. You then work down the list and if an item requires your attention you either do what’s required to close it, defer to later on or delegate to someone else to work. If an item does not need attention, but is only for information then you either file it somewhere for later use or to “incubate”, or throw it away.

GTD in practice seems to have the opposite problem to FC. It becomes a bottom up/push planning system that stresses urgency of a task over everything else, including importance and context.

FC says that efficiency as doing things right, but effectiveness is going the right things. GTD does not seem to help with the effectiveness part of the equation, while FC spends a lot of effort on it.

I spent little time talking to one of the GTD proponents about this, and he agreed that the system as written does not prioritize tasks in detail and it requires discipline to pick what really needs to be done, opposed to what is just as urgent but you’d prefer to do.

While FC has worked rather well for me for a number of years I’m looking for something that combines the list management/urgency of GTD. I clearly need to do some more reserch and thinking about this. Idealy I’d like a system I can sync my I-Phone into too.

A short Youtube video of a song about the ongoing Lunar Crater Observation and Sensing Satellite (LCROSS) mission looking for water on the Moon. It was written and recoded by John Marmie one of the mission project managers.

LCROSS PM sings about the mission

In football there is an oft repeated saying that luck evens itself out over the course of a season. There will be points dropped that shouldn’t have been, and points won that were not deserved.

The sounders have had their fair share of bad calls that have cost them points (LA, Chivas and maybe RSL), last night went a long way to balancing out the ledger.

Last night falls squarely into the lucky column, and it was a good night for it happen as games don’t get much bigger than this.

Going into the weekend the play off picture was incredibly tight, 6 or 7 teams chasing the last 4 play off spots. Seattle have had trouble scoring, were travelling cross country to play the defending champions, who happen to have a 22 game unbeaten home streak and Sigi managed them to that championship.

Seattle did not play their best, but winning when you are not playing well is one of the ways to tell a good side from the rest.

Seattle’s defence was solid with a few mistakes (Marshall penalty excepted). The back four were under the gun all night, Keller pulled off a couple of great saves, Schelotto missed a penalty, the woodwork got rattled a couple of times and Marshall acrobatically cleared a shot off the line.

Seattle had few clear chances. The goal was made by Ljundberg battling through two defenders, gave the ball to Evans. Who set up Montero with a very nice through ball. The keeper came off is line to play the angle on Montero and was totally out of position when the ball came to Levesque to put away.

It was a nicely worked goal, and very much against the run of play.

With the other results this week the 41 points they have are probably enough to ensure the play offs. DC, Dallas, RSL and Toronto have to win all their remaining games to push the Sounders out the top 8. One more point is enough to make it mathematically certain that we will see playoff football at Quest Field this year and the Dallas game will be an awesome celebration.

In March the ECS said “Tonight our history becomes legend”, last nights 1-0 win over the defending champions is going to be a large part of the story.

Tonight our history becomes legend – ECS

Just took part as a non-advocate review of after action review for a pure development engineering project that a friend of mine is delivering this afternoon. My projects have typically impacted operations and the factory, I don’t see development projects very often and it was fun to look at something new and be a neutral in the room reviewing the material I don’t have to deliver.

I noticed a few major differences in approach that may have value for my projects in the future.

Identify the primary requirements, in the example today that was three aspects of the deliverable, these were frozen and were off limits to change unless the revision was essential and had been through a formal process of reviews and approvals. I liked this, managing change is always an issue that takes inordinate amounts of time. While putting certain aspects of the deliverable out of bounds does require additional work during the define and charter phase, over the course of the project it pays dividends over the life of a project.

Integrating the concept of “fit, form, function, interchangeability and safety” into the change management process. I spent many years as a manufacturing engineer in a part number controlled world where revising any of the above requires a part number roll (-1 to -2). For production projects if a change in the deliverable (process, flow or physical part) casuses any changes to fit, form, function, interchangeability or safety then the project charter must be rolled to reflect the new “part number”.

Finally the deliverable was defined in the charter not only by physical properties and functionality, but also in how they would be inspected and measured. This avoids problems where an item passes shipping inspection, but is held for receiving inspection because of drawing interpretation or methodology. For a deliverables that reduces flow time, this would require the flow reduction measurement (touch time, wait time, end-to-end flow time or batch size) methodology to be agreed upon and documented up front.

The biggest takeaway was reinforcement of what I already believe; it all comes down to a watertight charter as the base the project is built on, no matter what the deliverable. Again I see a couple of new ways to really make it more comprehensive with out huge amounts of additional time being added to the charting process.

I enjoy taking part in looking at projects outside my usual realm. I typically get to look at something new or cool, and that makes my inner geek happy, but I also get to see how other organizations do things differently, see better ways of doing something and pick up new ideas to help my own projects.

Every project is driven by a requirement of some sort, the hard part is translating that business requirement into an end product that fully meets that business need.

My back ground is manufacturing, manufacturing tends to be a series of iterative steps that lead you to a product that fulfills the requirement. I try carry the same iterative approach to my project chartering.

Sitting in a meeting listeing to the sponsor tell you, in detail, what they want the project to achieve is easy. I have found time and time again that what the project team hears and starts working towards is not what the sponsor meant.

When the project only delivers part of what they customer wants (and thought they were paying for) there is typically plenty of blame to go around.

By the time the team, sponsor and whoever else is involved has discussed, reviewed, feedback and finally gained clarity as to exactly what the deliverable is and written the charter we have defined the following:-

Business requirements. All detailed requirements should be based on clear business needs. This comes from and executive sponsor, manager or someone with a very clear understanding of the project and the value it will provide to the customers

Scope. In my opinion the most critical part of the charter. It’s not only what will be included in the proposed solution, but also what will not be part of the project. It establishes exactly what the scope and limitations of the deliverable is so the various stakeholders (and the team) have an agreed upon standard against which they can evaluate the final product. Once agreed upon this is the baseline which the change management process starts with.

Context. Any business issues related to the project need to be clarified. Assumptions, priorities and ground rules need to be clearly stated.

Vision. A long-term vision for the new system and the need it will fulfil both when the project is complete, and into the future further along the product lifecycle.

One of the common issues this stage identifies is that the two groups (sponsor and project team) are not speaking the same language. Typically not everyone has a deep technical understanding or intimate knowledge of the process. If the scope contains too much technical language then the business requirements that we are trying to fulfill may become dilute or lost. This is why the business requirements should be part of the top level project document.

This step is all about reducing risk to the project and the project team. Taking a very thorough approach during the charter stage of the project, the PM greatly reduces the risk to the project, the project manager and the stakeholders.

By clearly documenting the project’s vision and scope in writing, and fully clarifying all requirements we create a proposal that will meet the business need, contain costs, and reduce the risk of failure.

I sat down with a friend for coffee this morning and spent a collective 20 minutes complaining about the frustrations, pressure, workload and all the little issues that make life difficult being a small part of something as huge as a new aircraft program.

Despite all the issues, delays, problems and so on, we both admitted to enjoying the experience, getting a lot out of it professionally and one day will be able to call this a career highlight. I’m part of a team that understands it’s role in the big picture, knows the deliverable, who we support and our plan.

It’s not fun in a race car/Disneyworld/beach in Cancun way. I’m enjoying the ride, get to spend time on the production floor and work with some great people.

I know am at my most productive when I’m having fun and feel fulfilled; I like being a project manager and I know the things that keep me engaged and interested.

Being creative – I’ve been in my current role for a few months and still see a lot of problems as a sustaining/production issues, the rest of the group has been here longer and are still in the “design/develop” mode even though we are in low level production.

Autonomy – I get to have considerable autonomy and freedom to do the job the way I see best. I have managers that trust me to get on with it and know that I will call out when I need help or guidance. They are fully aware that I’m not afraid to ask the stupid questions.

Getting my hands dirty – I come from a mechanical background and can go to the shop floor, speak “mechanic” and understand their unique problems as I’ve been there.

Innovation – projects that do not have a clear path to the product are far more fun. The more out-of-the-box thinking required the more engaged the project team is.

Learning – My group gets to touch almost every system on the aircraft and every time I get a project I get to see something cool, geeky and new to me.

There are plenty of projects, big and small, that are fun and challenging. However there are plenty others that are as dull as a monotone. I get a good mix of projects, both in size and complexity, but the really challenging projects involving with some new technology that make a difference keep it interesting and fresh. I like what I do and where I am in my career, and I feel fortunate to be able to say that.