Archives

Next Archive Previous Archive

01 Feb - 28 Feb 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005

Calendar

« October 2008
S M T W T F S
      1 2 3 4
5 6 7 8 9 10 11
12 13 14 15 16 17 18
19 20 21 22 23 24 25
26 27 28 29 30 31  

Stuff

Powered byPivot - 1.24.1: 'Arcee'
XML Feed (RSS 1.0)
XML: Atom Feed


Creative Commons Licence
This work is licenced under a Creative Commons Licence.

About

These are the archive pages of SwimBlog.
You can also use the search function on the Main Page to look for entries with keywords or phrases

+ 0 - 1 | § How Lean is My Review?

I'm sure most companies involved in engineering design and development projects hold Design Reviews, and sometimes Project Gate Reviews. These periodic events are probably considered as THE most important control points in any project - they are where key decisions are taken on the technical proficiency of a design, safety issues are considered, project progress and direction are checked, and commercial viability is assessed. Given the critical nature of these reviews, shouldn't we focus our efforts on making sure we conduct them as efficiently as possible, and that they add value to the process of product development?

If you are responsible for engineering projects ask yourself the following questions:

1. When attendees turn up at a Design or Gate Review, is this the first time they have seen the bulk of the material content?
2. Do you spend most of the time in the meeting explaining about the design/project rather than discussing issues and making decisions?
3. Do you end up in long detailed technical discussions, such as why power consumption is 3.2kW instead of 3.0kW?
4. At the end of the meeting do you have a list of actions requesting more information?
5. Does work stop in the week leading up to a review while you do nothing but prep?

If you answered 'Yes' to one or more of these, then you may have the focus of the meeting wrong. The fact that Design or Gate reviews are periodic means that much time elapses between them. Typically on a 18 month development project there may only be 3 or 4 reviews - i.e. one every few months. As a primary control and feedback mechanism then, a Design or Gate review is an extremely inefficient way of operating. If this is how your organisation uses periodic reviews you should think again.

Reviews should be seen as a 'final' chance for a group of people to take project decisions. The participants should be informed and involved all the way along. Reviews should spend as much time looking forward - e.g. planning how to resolve issues (note: not necessarily resolving the issues) and making decisions such as choosing between several options - as is spent looking backward over the work that has been completed.

If you are looking at improving Product Development project performance, look long and hard at how your reviews are conducted, and what effect the outcomes have on a project. I'm sure you will find plenty of opportunity to eliminate waste, and accelerate project delivery.

+ 0 - 1 | § The 'Human' Side of Project Management

You may be familiar with the Project Management Body of Knowldege (PMBoK). This is published by the Project Management Institute in the US in the form of a book called 'A Guide to the Project Management Body of Knowledge'. The book is a comprehensive collection of models and practices put together by respected Project Management practicioners from many industries. One thing that is clear in reading the book however, is how mechanistic the content is. As David Green points out on the Reforming Project Management blog, these and many other PM models "concentrate not on the project, but on ‘project management’ as though this activity of bringing projects to fruition has an independent importance". David points out that Project Management tends to be defined in terms of sub-processes such as Scope Management, Risk Management and so on. These terms just don't seem to get to the core of what Project Managers should be concerned with.

David proposes his own definition, which in my view succinctly distills the responsibilities of a good Project Manager:

1. Defining the outcome that is to be achieved (finished product, organisational change, etc by a certain time for a certain cost: quality of performance is implied in the basic requirement).
2. Facilitating activity to effect the outcome (getting the right people, resources and knowledge to work in an effective co-operative sequence).
3. Taking steps to avoid or prevent harms to the outcome (ie risk, change and stakeholder management, and developing metrics to forewarn of potential problems to allow corrective action to be taken).

This reflects that a Project Manager's role is essentially one of helping people to work colloaborativley to produce a certain outcome. The various PMBoK 'Managements' are merely collections of tools and methods that can be used to achieve this. I'm afraid that this subtle distinction can easily get lost. I have seen Project Managers get into in the detail of producing Gantt charts, risk registers, issues lists, Earned Value charts and so on, and not focus in on the actions that actually help the project to succeed.

+ 0 - 1 | § Real-Time Performance Feedback

I just listened to a very interesting podcast from BBC Radio 4's 'In Business' program about the Infomercial business in the US.

It was fascinating to hear how sophisticated and complex the sales techniques are. The producers and presenters of these shows are able to fine-tune the content of the program by analysing feedback on the number and rate of calls and sales dollars generated in real-time while the program is on air. Even while the presenter is on camera, he or she can see a monitor just off to the side with the sales data as it happens. This can be a great motivational tool, and can also help the presenter to modify his/her focus and approach as the program progresses.

Now, just think about the performance indicators you typically have at your disposal on your product development projects: percentage complete, milestones passed, number of drawings issued.... any more? How many of these are already several days or even a week out of date by the time you see them? How many tell you about the rate of progress and whether or not at that rate you stand a chance of succeeding? How many different places do you have to go to find this information? What do these indicators tell you about the technical maturity of the project, or confidence in the product's ability to satisfy customer needs and generate sales?

With modern databases, PLM packages and Project Management software, there really is no excuse for not having a 'Dashboard' of indicators that give you a good mix of backward looking and predictive indicators. All it take is a little effort to figure out what information would be useful, how to store and retreive the data, and how to present the results in a meaningful way. Oh... and put it right where people can see it.

(note: if you want to listent to the podcast yourself, I believe it is only available for download from the website for 7 days after original transmission).

+ 0 - 1 | § Design Data Re-Use

In a recent CAD interoperability survey carried out by CAD Vendor Kubotek, an interesting fact emerged on CAD model data re-use. The survey asked respondents "What percentage of the CAD models which you produce is generated completely from scratch?". The results were:

All models created from scratch - 18%
Three-quarters of all models created from scratch - 22%
Half of all models created from scratch - 20%
Quarter of all models created from scratch - 23%
No models created from scratch - 17%

This looks like it supports the prevailing theory that CAD helps users to become more productive through re-use of existing models. Fewer than 20% of users never re-use any of their old data, and 60% of users re-use half or more of their existing data. Good news it seems. However, it would be nice to dig a little deeper and find out the actual productivity gains for these users. In my experience, many companies do not put much effort into creating their CAD geometry with re-use in mind. Too often it seems that standardised modelling techniques and advanced CAD functionality like parametric design and common feature sharing are not widely used. It's a bit like creating an excel spreadsheet to record your monthly business expenses and not using formulas for calculating totals and sub-totals.

Given the relatively high degree of re-use of data among respondents, this is an area ripe for improvement in any Lean design initiative.

+ 1 - 0 | § The Ratchet Effect

Have you ever noticed how expectations always ratchet upwards? The better something is, the more people tend to expect from it.

I was in conversation the other day with a young Design Manager in a client company who was bemoaning the fact that it took too long to open up a full digital mock-up CAD assembly (containing several thousand parts). While I can understand his frustration in having to sit and stare at a blank screen for several minutes, I did have to gently remind him of the things he and his team can now do with that model that have shaved days, if not weeks off the development schedule. For example full clash detection and minimum clearance checks in minutes rather than spending days poring over drawings with a calculator, instant Bill of Materials creation and maintenance instead of updating spreadsheets and parts lists on drawings, instant estimated weight calculation and management .. the list goes on.

Having seen the spectacular growth of CAD from the early days of command-driven, 2D wire-frame drawings, through to 3D intelligent solids and full digital mockup, the sheer power of most modern systems still impresses me. As an engineer and manager, I have experienced first-hand the productivity gains that come with that power. However there is now a generation of designers and young managers that have never known any different. At the time, I thought that the Design Manager mentioned above was being a little overcritical, but on reflection I believe he has the right not to be impressed when something like opening a huge CAD model causes a bottleneck in his personal productivity. We need to keep finding ways to continually improve - we just need to make sure our ratcheted expectations are put in perspective.