process | Dave Kean

Tag Archive: process

A little creativity

Written on March 28, 2011 by Dave in PM stuff, Work

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.

4 Comments - Leave a comment!

Earned Value for the easily ammused

Written on September 16, 2010 by Dave in PM stuff

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.

0 Comments - Leave a comment!

My problems with meetings (and an idea or two)

Written on May 23, 2010 by Dave in Stuff...

“Meetings are an addictive, highly self-indulgent activity that corporations and other large organizations habitually engage in only because they cannot masturbate” – Dave Barry

I spend a significant portion of my day in meetings and often come out wondering what was accomplished.

I consistently see the following problems with meetings at work:

No agenda, or even worse a vague agenda with little direction
Someone in the room will have nothing of value to add and insist on adding it
The full scheduled time will be used
They breed; one meeting usually leads to another
Typically about an abstract concept, not a concrete product or decisison
They take preparation time
End up totally off course
The information transfer is typically minimal

Today I spent two hours in a room with 9 other people preparing a presentation. That’s not a two-hour meeting, it’s 20 hours of time. I work for a company that does internal quotes and business plans in hours. This meeting was a considerable expense.

A considerable amount of the time was caught up in arguing the nuances of language and listening to people who had nothing to contribute, but an existence to maintain. As with all big companies there are people who justify by filling up their calendar and adding nothing of value.

A meeting is not the place to create a pitch, it’s a place to get the team together to approve the changes they’ve previously submitted are correctly incorporated by the content owner. This was a couple of hours of my time and 20 hours of the companies time wasted.

A previous employer used to have gathering areas on the production floor, no meeting rooms. The philosophy was we were coming together to share the resolution, not rehash the problem. These meetings rarely lasted more than a few minutes and were as effective as 10 people sitting around a conference table hashing out a pitch.

There are some great tools, email, sharepoint and other online communication or colaberation tools, this allows me to manage my own time. When we meeting face to face at work the group seems to automatically assume they have an hour of my time, which seems to be the standard meeting length, and will take all of that time.

In an email I might grasp their concept within 2 minutes and be ready with a reply. Other times I need to think about their message overnight. All of this is impossible in face to face meetings where an immediate reaction and 100% dedication is demanded of the participants.

If you can’t avoid it and actually have to call a meeting: First is that it takes a leader to keep the group focused, and know that just because Outlook can’t easily handle bookings of less than 30 minutes, you don’t have to use every second. Make a very clear agenda and let people know what they need to come with. The meeting is a place to make decisions, not inform and create content.

Keep the numbers down and make the meeting for those that really need to be involved, the oxygen wasters who need meetings to validate their existence really don’t need to be there

The final, and to my mind the most important part of a meeting is when everyone walks away and the decision that’s made. Know who is responsible for recording, sharing and finally implementing the results.

1 Comment - Leave a comment!

What do you do with lessons learned?

Written on October 16, 2009 by Dave in PM stuff

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.

1 Comment - Leave a comment!

Goal setting at Toyota

Written on September 26, 2009 by Dave in Work

In manufacturing the Toyota Production System (TPS) is the benchmark that all others measure against. Many companies, engineers and academics have spend a lot of time examining how Toyota does what it does, and I’m no different.

There is a lot to be admired in Toyota and how they do things. I spent a little time examining how Toyota moves forward and a very large part of the success of their product line may be the setting of tough goals. Just setting the goal and expending the necessary resources to make it happen is a small part of it, it’s allowing the people to own and take responsibility that makes their approach a little different.

Setting challenging or nearly unobtainable targets like “a full product line in every country” forces the company to look for new ways of doing things and break away from established routines.

The goals are purposely left rather vague, this allows organizations to explore different strategies. It can force groups to move outside their usual functional group and collaborate with others (both internally and externally) to find the beat solution as no “right solution” exists.

This teamwork has been always central to the TPS, on the functional level each member of the team is responsible for the sucsess of the team. Teams and the TPS see these obstacles not as problems, but as opportunities to be overcome and make the team and product better. Never settling for today and continually looking for incremental improvements to go along side the leaps in technology allows Toyota to make these big goals.

Toyota believes a car can contribute to a fulfilling a need , and by association making people happy. By wanting a full product line in every country Toyota links customer fulfillment directly to its employee’s endeavors.

Toyota says they don’t make cars, they enhance people’s lives. From my dealings with people from Toyota, employees really believe this to be true. It’s buried deep in the company DNA and is why they strive to be better tomorrow.

Other companies look at the TPS, transfer some methodology, empower people to own the process, but miss the part about making the customer happy being the most important part.

9 Comments - Leave a comment!

Checklists…

Written on September 9, 2009 by Dave in Work

I work in aerospace, possibly the most process driven industry around. Most if not all organizations that support the design, build and delivery of products use checklists. Salesmen configuring the aircraft, design engineers preparing a drawing to pilots preparing from the first flight, all use some form of standardized checklist to ensure that things get done in a consistent way and is ready for approval and their downstream customer.

Where the flow of incoming data and tasks is so overwhelming that you have no idea what to do next (called “task saturation”) going to a checklist allows you to focus on priorites and work down a clearly defines list.

At work we have two primary uses of checklists.

Reminder checklist – complete the tasks, then look at the checklist to ensure the item is complete and ready for the downstream customer.
Challenge/response – one person reads out the item on the checklist and a second person completes the item and then calls out the correct response.

Content

Chunking – List the items that should be on your checklist. There are a number of ways to group items. Those that share a common factor (location, function) or group by priority.

Flow – examine the chunks and look for a logical progression (moving around your desk, the order in which people need to approve a drawing) to make the list more efficient.

Completion Box – If it’s just one person working down the list then a line that reads “Section complete” and a tickbox is all that’s required. This allows you to move on knowing the previous section or group is finished.

Redundancy – If there are items that consistently cause rejections or are especially critical it’s OK to duplicate them.

Size – Make your checklist as short as possible but as long as needed. The longer the checklist the less likely it will be used and the more likely you will be interrupted while using it.

Design

Font – Use a very clear font, a single font in a mix of upper and lower case is ideal. Italics can be used for emphisis. The idea is the eyes should quickly pick put to what they need to see. Use both upper and lower case letter.

Use black lettering on white paper. Highlighting can be used to define critical items.

Phraseology

Terminology – Use proper terms, as this reduces the chance for error. No vague or ambiguous phrases.  Status – Use the actual status or condition that is desired after each item. For example

“Engineering sign off . . . . . Complete”

“Master Power . . . . . . . . . On”

“Tourque wrench . . . . . . . . To 70 ft lbs”

Checklists are there to ensure things are done in a consistent, systematic way. When we are under pressure to meet a deadline whether it is releasing a piece of design engineering, a plan to the shop floor or a part for delivery to a customer its possible to miss a step.

When I get a request from the shop for help I can meet their needs knowing that I’ve done everything needed. My output will be complete, correct and that my actions and response were thought through when I had time.

0 Comments - Leave a comment!

Buisiness requrements should drive the charter.

Written on August 17, 2009 by Dave in PM stuff

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.

0 Comments - Leave a comment!

Turning problems into good visibility

Written on July 26, 2009 by Dave in PM stuff

Like most project managers I’ve typically tried to manage roadblocks and issues behind the scenes with out raising too much of a fuss. This is usually effective in getting the results I require with out drawing too much attention or using too much political capitol.

However there are times it is best to get a problem out in the open, almost always in conjunction with the behind the scenes work, not instead of. Lining everything up first with your usual communication plan before airing the issues in a more public setting makes sure no one gets surprised.

In the past I’ve usually booked a special meeting of the Project team to address a specific problem or issue that’s causing the roadblock.

A lot of PM’s and some sponsors can see this as a failure of the PM process, however I believe more often than not, calling the “trouble” meeting can benefit the PM directly:

While you may not have foreseen the problem in the planning stages calling a special meeting helps build your credibility because you recognized a problem that the project needs help with and not everyone was aware of.

It also allows the PM to proactively manage the attention given to their project by leadership. This attention is a limited resource that you want to use only when needed. Gets the people you need further u the food chain to pay attention and is used to solve both systemic problems (process) and tactical problems (project).

Perhaps most importantly it shows that you are “Managing the Project”, often a PM’s skills are may not be visible to senior managers and this gives people outside your usual reporting structure that you working to keep things under control.

Meeting with the project team allows people vent, and encourages participation in the solution, which improves buy-in, and makes your change job easier.

If you find yourself confronting a significant problem or barrier in your project, call a special meeting, and get the problem out in the open.

Your project and how you are how leadership perceive you will benefit.

0 Comments - Leave a comment!

Thoughts on Value Added

Written on July 20, 2009 by Dave in PM stuff, Work

I spent some time recently reviewing the Value Stream Maps of a couple of processes and identifying the steps that the customer (the production floor) really cares about and those that don’t add value.

Here are my thoughts after identifying a number of steps that don’t add value to the customer, but are still essential part of the process.

Non-Value Added (NVA) – any activity that is not required by the business or the customer willing to pay for. The NVA list is extensive and includes storing, moving, reworking, obtaining multiple approvals or signatures for the product. As I said the list is extensive.

Value added activities can be divided up into two categories -

Customer Value Added (CVA) – this is the stuff the customer cares about, turning aluminium into airplanes, writing code and adding functions that provide additional features that the end user cares about. If the activity changes the form, fit, function, interchangeability or adds a feature then it probably adds value to the customer. Additionally any work we do that provides a competitive advantage, for example eliminating defects, reducing price or reduction in flow time, falls under this category.

Process Value Added (PVA) – activity or expense that is required to operate the business and the customer does not care about. There are a considerable number of tasks that are required (or even essential to the process not breaking down) but don’t add anything to the product.

It’s obviously important to eliminate NVA activities. There is inevitably some low hanging fruit that’s easy to remove, however it’s important to delve deeply into the process and really understand what each step in the process adds and eliminate all NVA tasks and steps.

Recognising PVA and separating them from the NVA can be difficult. You are required (by law or by some form of regulatory body) to perform there steps, but they don’t add anything to the product. First step is to confirm the step is required, then look a little close of see if it’s performed as efficiently as possible, this may require contacting a subject matter expert to really understand. Ideally you’d like to eliminate PVA, but that’s typically impossible for a true PVA step. Then you are required to ensure the cost of these steps is reduced as far as possible.

3 Comments - Leave a comment!