Dave Kean

One of the issues I’ve had in my life is creativity, I was looking at this and my hobbies pretty much all revolve around rather structured activities. Racing, football and so all have very comprehensive rulebooks. I’ve said before,  F1 being an engineering/money exercise, there is some allowance for creativity, but that’s done with in the frame of a very comprehensive rule set.

Professionally it’s a similar story. Less so than in past positions perhaps, but none the less it’s all very structured.

One thing I do see is that the more successful project teams and project managers have some level of creativity when it comes to examining and solving problem. True creative thinking isn’t always a straightforward thing to achieve. There are some interesting tools available, I spent an hour this afternoon listening to a pitch on “Idea Mapping” that was given by Jamie Nast and it is a very interesting approach and gave me a lot to think about. Followed by a quick order for Jamie Nast’s book from Amazon. If you want to learn a little more about the Idea Mapping the author has a rather good site at “ideamappingsuccess.com” it’s worth a visit if have even the slightest interest.

However I find flowing ideas and thinking outside the box is not always easy and I’ve been thinking about this a little tonight.

Preliminary

Before we get stuck into the cool free-thinking stuff, we need to understand the boundaries of the project. As Formula-1 has a very comprehensive rule book, every project I’ve worked on or led has some constraints around it so while we are trying to add a little creativity,

Thinking

Take time, but be quick. I get that does not make sense, but… Give yourself a chance to really think in-depth about the problem, but don’t be too deliberate. The creative juices have to flow. I have found carrying a notebook around with me and have started using it to jot down little things through the day. They may not make much sense and occasionally look suspiciously like a shopping list, but I do think little things like this are making a difference.

One thing I do know is not to be slow in asking peers or mentors for their though and ideas. I do have a great mentor who is decently far enough up the food chain that he has a very different view of any particular problem. There have been a number of times that a thought or insight that directed me in a new direction.

One thing that’s been working well in the office is questioning the assumptions. A lot of the process work on my program was done years ago in something of a vacuum. A lot of assumptions were made that are not necessarily correct today. We can change processes, and as time goes on processes may need to change, they should certainly be challenged occasionally. I really don’t think you can come up with a good solutions if you have are starting with incorrect assumptions, so examine your situation and the problem, then have someone else from a different office look at it. Peer review can only make it stronger.

Somewhat related to the peer review is looking at the problem with a slightly different set of ground rules. How would a smaller company handle it? What is we had fewer resources and had to innovate a little, How would we do it? It may throw up innovative solutions that a conventional mindset may not have yielded.

First contact with reality

Yes despite all these ideas (and thousands more) the solutions need to stay within some boundaries, in aero regulatory and certification requirements impose quite a ridged box around how we do things. At some point you have to stack these constraints up against the solutions. I hope you have as much luck with that as I do.

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.

Made it to Disneyworld and the conference after a couple of delays, the PM track is very full and a couple of excellent papers tomorrow that are dealing with decision making and EV metrics that I’m actually rather looking forward too.

As good as the PM stuff is, the restaurants at Disney are even better. Last night a few colleagues, old and new, and I ate at Todd English’s seafood restaurant in the hotel. Some of the best seared ahi I’ve ever had.

The Dolphin Hotel

Conversation turned to memorable moments growing up, those times we look back on and know that was special.

My special moment growing up was easy, going to see Star Wars for the first time. I’d never seen anything quite like it, from the opening sequence where the Imperial Star Destroyer is chasing the Rebel ship with the Princess on it, to the moment the Death Star exploded, I’m not sure I blinked once.

I went with dad to see it in the first week it was released in England. The queue at the Odeon cinema at the top of Guildford High Street was all around the side of the building when we arrived. During that first release I ended up seeing it three times, twice with Dad and one final time with mum who complained it was too loud for her.

For an 8 year old it was something else, I think it’s safe to say that no cultural event has had a similar impact on me in my life. At the point my pocket money went on the bubble gum cards, plastic figures and at Christmas I got a lightsaber.

OK, it was really just a torch (flashlight) with some opaque tubing attached to it, and it only really worked if you stood in the dark. Still I did not care, I had a lightsaber and 8 year old me was a Jedi damn it!

I do remember trying the Jedi mind trick on mum, she of course did not get what was going on. I was asked to clean my room, a mundane chore that took me away from either Saturday Swapshop on the TV or killing Stormtroopers and rescuing princesses depending how interactive I was that day.

I replied to the request (reasonable request BTW) with sweeping my hand through the air and saying “You don’t need me to clean my room…”

Mum was clear “Yes you do.”

With another sweep of my hand “You don’t need me to clean my room”

“Yes I do, and why are you waving your arm around like that?”

I tried to explain that I was trying Jedi mind tricks I’d learned from Star Wars. I was probably at least a little disappointed that the Force was not as strong with me as I’d have liked to believe.

I was then told to put the Force to work picking up my crap off the floor of my bedroom…

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.

I’ve put down my thoughts about how experimentation is one of the central tenants that separate TPS from it’s imitators. This Plan-Do-Check-Act structured approach requires well thought out specifications and a high degree of structure.

Conventionally this structured approach with a reliance on clear concise documentation would indicate a very ridged command/control approach with little flexibility given to the various organizations. At Toyota the opposite is true, organizations are challenged and left to get on with it with little management oversight while the project is unfolding.

To translate this to a production system is straightforward. There may be a number of good ways of doing something, experimentation will find the best. Once this best way is found, it will always be used unless something drives a change.

The operator putting wheel nuts on will put them on in a certain order, over a certain time, using specified tool.

The work is highly specified. The content, timing, sequence and expected outcome are clearly known to the operator, who happens to be responsible for his own quality. In this case the outcome is four wheels installed with twenty wheel nuts to a set torque value.

It sounds really simple, the difference is in the details. In a vast majority of production shops the sequencing of a job is not documented to this level of detail. Typically new operators are shown by experienced employees how they do a particular operation (like fitting the wheels). There is no clear, unambiguous specification to follow. No experimentation has been done to refine the best way and variability still exists, and where you have variability you allow room for errors to happen.

Toyota clearly does things differently. First a new employee is taught the right way to do the job they have been assigned by their immediate supervisor, not the person doing it last. No bad habits are handed down, only the correct sequence. The next part is possibly the biggest difference, each employee is required to be able to answer the following for each of the jobs they are required to do.

• How do you do this work? (Plan)
• How do you know you are doing this work correctly? (Do)
• How do you tell the output is free of defects? (Check)
• What happens if there is a defect? (Act)

This continual questioning of the process and how the operator is doing it brings us back in a full circle to the “Plan-Do-Check-Act” mantra that runs deep through the development cycle. We can see is also at the center of the production processes.

This is also where the moving line becomes so important, at any time anyone familiar with the system can look at the location of the car being put together and know exactly what state of build it should be in. It works just as well for 737 jet liners as it does for a Toyota Yaris.

If the car/jet has hit a certain location in the factory then the seats should be in the process of being installed. If the seats are still sitting on the side of the line waiting for another process to be completed then we have a problem and the line is stopped. The line is not restarted untill the issue is resolved. In the case of the 737 manufacturing, design and industrial engineers are collocated with in yards of the line and their sole job is to solve the issue and restart production.

I sat down for coffee with a couple of friends who facilitators workshops internally (AIW and 3P for those who speak LEAN+) and discussed project close out. A lot of projects seem the just trail off after the item or process is delivered and eventually vanish into the ether when the SharePoint site is closed and archived.

Closeout is the final phase of the project and is the first time we can really judge the success of all the work put into chartering, change management, the begging for resources and execution of the plan. I think it’s an important part of the project and determine the completeness of the project against the objectives we agreed upon up front.

One issue that seems to happen again and again is people leaving the project after their deliverable is completed, often prior to the closure of the project. While the customer primarily cares about the deliverable, the PM organization and project team members miss out on a post-project review and sharing the understanding of what worked and what did not.

Conducting a post-project review and capturing best practices to share with the PM community should be an essential part of the closeout phase. By not having a formal lesson learned or project review archive a significant amount of experience is not available for and important material is lost.

The PM community at work has an informal lesson learnt database and monthly lunch time “brown bag” meetings to share as a group, but there is not a formal process to manage the close out process and archiving.

I’m interested in seeing how other organizations handle this close out, recording and sharing lessons learned with their PM community.

In contrast to Toyotas and their often vague, but challenging goals NASA uses a very different requirement process.

They break the goal setting into four distinct actions before authorizing a project.

Need – every requirement for a program or project should be fully understood and how this requirement is needed to fulfil he project goal. The idea is clearly to stop unnecessary items (or work statement padding) before it starts. NASA feels each initial requirement should be examined as closely as any change coming through a robust change management process.

Attainable – If the project goal is unattainable with the assigned project resources then the project is a waste of time and effort. There may a need for feasibility studies, technology demonstrators to prove concepts or firm up what started as an educated guess. These risk reduction activities need to be part of the project plan and the results of which may drive gate decisions.

Verifiable – Each requirement needs to be examined closely and clear criteria included in how it will be verified. There should be clear pass/no pass criteria that are not subjective and therefore unverifiable.

Accountability – This is seen as important for each individual requirement and ownership of each requirement should appear on the charter or requirements document. NASA feels the owner should be a person with a stake in, be knowledgeable about, and understand how success will be measured for each requirement. The owner needs to be involved in all change managmenent activity that affect their requirements.

NASA, like the rest of aerospace, works extensively with specifications as a risk reduction strategy. A specification control document identifies the final functionality, environmental quality, foot print, interface and so on of the final product. Be it a complete launch vehicle or a small component of that launch vehicle.

The accuracy of a specification is every bit as import as any other requirement document.

This contrasts with Toyotas approach where goals are purposely left rather vague to encourage organizations to explore options and encourage groups to collaborate with others (both internally and externally) to find the best solution.

In a far more risk adverse industry the goals are very clearly stated and the way in which they will be met is left open a little more.

It’s an interesting contrast in style.