Project Managers Risk Averse? - Part VI

 

Since project resources know management is likely to load them up with more new tasks they protect themselves with due date promises that take into account what is likely to happen (more tasks) and more multi-tasking. Management can stop this by ensuring fewer active projects in the system at any one time. Flow should be their number one priority!

6. Increase Project Flow – Take Advantage of Little’s Law

(See a Resource Standing Idle is a Major Waste)

In Part III we saw that the belief "a resource standing idle is a major waste" must lead to multi-tasking and as consequence projects take longer, projects are at risk of missing their due dates and budgets because of the added time, and resources must be frustrated by all the changes in direction they must make – switching between projects. Project managers must be frustrated by the due date and budget problems they face.

Lets change the practice. Professor Little tells us less is more. If we have fewer active projects, then multi-tasking must be less and according to Little speed and quantity will increase. If speed and quantity processed increase, then due date and budget reliability must also get better. Seems simple. (You saw the potential if you played my little game described in a previous post)

So, lets stop (freeze) at least 25% of all projects. To do that we need to have unambiguous, unequivocal priorities to decide which projects will be worked on and which will be stopped – for now. This might be difficult!

Once we have made the initial step (at least 25% of all projects are frozen) then we might as well tell resources to always finish a task they have started before they tackle a new one. (there may be exceptions like situations similar to writers block when a resource needs a ‘change of air’ to get going again.)

If we freeze at least 25% of projects then some resources may be idle. Since many times projects and project managers complain of inadequate or insufficient resources we can now staff projects more appropriately – so lets also do that.

There may still be time available for some resources. Projects (initial tasks) are often started without having completed the necessary preparations. Now resources should be available to complete such preparations quickly – for those projects still active and those soon to be thawed and restarted.

When I describe the situation like this it seems to me that with 25% or more of projects frozen I run the risk of considerably speeding up project flow – and I don’t see any negatives for the organisation or for management.

However, I see a really big obstacle – it is ‘a resource standing idle is a major waste’ and management behaviour in relation to this. If a program or portfolio manager wants to try something like this, then he must ensure management support before he starts. Without that support the frozen projects will almost certainly be forced to restart again – before it is time.

Tell me, what are the risks of ‘FREEZE’, if any?

Imagine what could happen to the flow of projects in your organisation!

If flow, speed, quantity and reliability all get better, what are the implications for your organisation – for profits and profitability; for project costs; for customer satisfaction? Let me know please – the impact will likely not be the same for everyone, every project environment nor every company.

References:

1. http://web.mit.edu/sgraves/www/papers/Little's%20Law-Published.pdf
2. http://en.wikipedia.org/wiki/Little's_law
3. http://mitsloan.mit.edu/newsroom/2006-little.php

Technorati Tags: 6-Sigma, Continual Improvement, Cost, Costing, Critical Chain, Efficiency, Execution Management, Goldratt, Project, Project Execution, Project Management, Project Manager, Risk Management, Theory of Constraints, TOC, Little's Law

iv>

 

Project Managers Risk Averse? - Part V

 

Rather than worry about risk, lets imagine. The next question will be – how can we achieve what we have imagined? Please, if you can imagine more, add your imagination to the list.

5. Imagine!

1. Imagine your projects flow ‘like a river’ to completion. Imagine projects flow like a Japanese production line – fast, effective, and no failures. More projects are reliably delivered on time.
2. Imagine you, one of the resources in your company’s projects, can focus 100% on the task at hand. Once you start a task you are not interrupted by anyone until that task is complete. Will this speed up your work? Will the quality of your work improve? Will satisfaction increase as you do more good work more quickly? Will the value of your work increase?
3. Imagine you, one of the company’s project managers, can always finish your projects (100% of the scope) on time, within budget. If there is a delay it is much smaller.
4. Imagine your organisation helps you and your team always complete your projects on time – imagine the organisation knows the status of all projects. The clear priority is to finish all projects by their due date.
5. Imagine top management can see, every day, the status of all projects – those that are doing fine, those that are OK but need watching and those few that need help to get back on track. Imagine a big TV screen that tells everyone in the organisation what the correct focus is.
6. Imagine risk is almost always dealt with successfully.

 

Eli Schragenheim thinks aloud – 5 webinars on Decision Making

Eli Schragenheim is a good friend and someone I talk to a lot to check my own thinking .... and not incidently to learn from his insights.

Eli sent the following to his friends in the Theory of Constraints community - but his insights are good for others too:

My dear friends and colleagues in the TOC community,
From a perspective of more than 25 years in TOC I like to share with you thoughts about what I believe are some of the most important challenges for the future. TOCICO is given me the vehicle of delivering five consecutive webinars on the broad topic of Decision Making in The TOC Way, starting on January 8th 2011. The first topic encompasses the scope for the whole series: Between Complexity and Uncertainty.
In the first four webinars I like to share with you a certain broad direction of making decisions, especially within the context of an organization. I believe people behave differently when they decide for themselves and when they decide on behalf of their organization. The clear objective is to find better ways and tools to make superior decisions for organizations, and then it should have a lot of impact on individual decision-making.
If you know people who might interested in these webinars, please, forward this email to them. We all like to spread the TOC thinking around the globe.
In order to register go to: http://www.tocico.org/?page=upcoming_web 
Be well
Eli Schragenheim


The TOCICO that is hosting his webinars is also a great resource for Theory of Constraints knowledge


I hope many of you will attend his webinars - either life or to listen to the recordings which I am sure will be available.


Rudi Burkhard

Getting Rid of Shortages and Surpluses - Free Webinar

Tuesday, January 18, 2011 · 6:00pm - 7:00pm 

Surplus stock has always been a problem for retailers and their suppliers. Nobody yet knows how to forecast what the consumer will buy next season. If we knew how to forecast accurately, nobody would have end of season discounts or factory outlets. Surpluses are, today, a fact of life for almost any distributor or retailer. How much of a season’s purchase do retailers have to discount? 30%? 50%?
Wouldn’t it be nice to have only about 10% left that needs to be discounted? To do that a retailer must not buy what the customer is not going to buy. Why can’t we do that?

That is the story about surpluses, but what about shortages? If we have as many shortages as we have surpluses then our business is losing a lot of money - Every missed sale costs the selling price less materials cost to the bottom line.

Register here: https://www2.gotomeeting.com/register/320873019

Hope you join us!

Project Managers Risk Averse? - Part IV

A recent (late 2010) “Linkedin” discussion started with: “I was at a live project manager networking event the other night and someone said, ‘Project Managers are Risk adverse by nature.’ Is risk adversion a quality of a successful project manager?” What are they really talking about? The discussion seems to conclude project managers are not anymore risk adverse or averse than any other person. What they do is manage their risk. I thought I would write this article about risk in projects, how risk is planned for (in the project plan) and how risk is managed during project implementation.

 

4. Front End Loading (FEL), Project Estimation

Management generally wants to know the economics (or financial impact) of a project before they authorize it. Understandable because most of the time projects, apparently at least,  do not deliver on their promises.

Investment projects are justified by the investment made (early, negative cash flow) and the profit that will be generated (delivered later, after project money is already spent). Project expenditures are monitored and accounted for, but how often are the actual profits generated measured after the fact. The project may take a year to implement, another year to reach a normal level of income and several years before the initial investment is paid back. By that time the original project is forgotten and nobody analyses what was said and what was achieved. Many times the managers that proposed and authorised the project have moved to a new job. Analysis seems pointless and a waste of time.

Not only does analysis seem pointless and a waste of time but current reality is much more important to be dealt with. Post mortems will not change history and probably will not have much influence on the future – the Wold changes so quickly.

Management of course knows all this and therefore reacts accordingly – they put a lot of pressure on project planning to get an accurate estimate of scope, time and budget. In an FEL process the accuracy of the plan is fine tuned until (at least this is the target) an accuracy of say ±5% is achieved. My question: Is it a wise thing to do all this work to get to a ±5% level of accuracy?

Project estimate accuracy – whatever is being estimated – is subject to diminishing returns. The more accuracy we desire the greater amount of effort (time) and money will be required to achieve it. At what point do we decide the view is no longer worth the climb? Do business and project 
managers invest too much time and money to get the accuracy they need? The more time and money spent the more risk averse the manager is – or seems to be. But, what is the impact on the value of the project?

What should a manager consider when estimating his project in terms of scope, time and cost? Here is my list:

1. Is the scope of the project complete enough? Are the specifications complete enough?
2. What is the estimated cost of the project – including project estimation?
3. How long will the project take – from the point in time we decide it has a good chance of being a profitable project?
4. What is the expected cash outflow including timing from this project?
5. What is the expected cash inflow for this project – including timing?

As everyone realizes we have three parameters that are important – cost (investment), income and TIME.

I believe TIME is the parameter that is neglected. The impact of TIME on a project’s payback, net-present-value or other such valuation is misunderstood and often not taken into consideration – at least not correctly or sufficiently.

Most of the time a project is valued from the moment it is decided to invest in it – after a lot of time has already been ‘lost’ to prepare an accurate (±5%) estimate. To determine the real value of a project look at what would have been the payback had you made the decision much earlier, but with significantly less accuracy? The impact of this lost time can be very significant – this lost time postpones both expenditure and income. If you include the expenditures made during estimation then the impact increases. Even more importantly the market is continually changing so that the information used to launch the estimation becomes less and less valid as time goes on. There is a chance that at least a part of a market opportunity will be missed.

The impact of TIME becomes important if the project is shortened (from the decision point to go for it) and if the market is volatile enough that a delay might cost market share and sales (new product development is almost always in this situation as is investment in production facilities to expand supply capability. Many companies have lost market share because investment took too long).

TIME is an extremely important factor in projects – the faster you are the more market share you can capture – or the longer you can delay a decision for a project. This statement is generally true – and yet projects often take longer than they should (multi-tasking).

Consider the difference between ±5% and ±20% estimate accuracy. If I decide to accept the less accurate estimate I am able to the start the project much earlier and finish it much sooner too. My product will be earning back the investment much sooner – and I have saved some estimation costs.

If I have a ±20% estimate will I waste money? I do not see why this should be so, my purchasing people can still do a good job of obtaining the best possible value for my business. The best value may also NOT be the lowest price. TIME will again be the essence – it will be profitable for me (usually) to allow my suppliers to earn a better return in exchange for speed (and quality). Speed (TIME) will pay back much more than I will have to spend for value.

You can test what I am claiming by building your own project model to show the impact of TIME and much shorter estimation periods on the payback and profitability of your projects. Be sure that you consider all aspects – including the impact of less accurate estimate on both investment and future returns.

If TIME is s important, and multi-tasking is another TIME waster – what could be the impact on a company if much less TIME is wasted?

Technorati Tags: Critical Chain, Execution Management, Multi Tasking, Product Development, Project, Project Execution, Project Management, Project Manager, Project Plan, Risk Management, Strategy and Tactics, Theory of Constraints, TOC

iv>

 

Project Managers Risk Averse? - Part III

A recent (late 2010) “Linkedin” discussion started with: “I was at a live project manager networking event the other night and someone said, ‘Project Managers are Risk adverse by nature.’ Is risk adversion a quality of a successful project manager?” What are they really talking about? The discussion seems to conclude project managers are not anymore risk adverse or averse than any other person. What they do is manage their risk. I thought I would write this article about risk in projects, how risk is planned for (in the project plan) and how risk is managed during project implementation.

 

3.  Management Practice “A resource standing idle is a major waste.”

This belief leads to a misuse of resources and consequently lost time in projects. Task and project time estimates must, of course, take into account that this belief is common and that it has a major impact. What follows explains why.

I suspect that no manager likes to see employees loafing – they should all be working all of the time. If they are not working (so it is believed) then the company is paying salaries and getting no results. Is this belief the case in your company?

Employees suffer from the same thing. If they have nothing or too little to do they feel their job is at risk. If they are not working then sooner or later their position (they believe) will be eliminated and they will be looking for a new job. Employees must therefore go out of their way to make sure they always have enough work on their desk. If there is not enough they spread work over time and make sure more work comes their way soon. Everybody wants to be (or at least must look) busy all the time.

In many project environments it is quite easy to keep everyone loaded with work. There are plenty of projects that need to be done. In fact, isn’t it true that many times there is pressure to start new projects before existing active projects are finished? It seems there is often pressure to start the next urgent and important project as soon as possible (maybe because it is well known that projects are generally late so starting as soon as possible seems to make sense).

Management, project managers and employees all have the same aim – have as many projects running concurrently as possible. In this way everyone is busy, no one is in danger of being fired and new (urgent) projects are started straight away. Is this common sense or common practice in most project environments?

Little’s Law (John D.C. Little; Professor of Marketing at the MIT Sloan School of Management - in operations research. He is best known for his proof of the queuing formula L = λW, commonly known as Little's Law). He tells us that the more work we have in the process, the longer the lead-time of the process. Little’s Law states that the common practice of keeping everyone busy and launching projects as soon as possible will cause projects to take longer than they could or should.

When many projects are implemented in parallel resources will be forced to work in at least several of them concurrently. Project managers pressure resources to work on their projects causing these resources to abandon a task before it is finished to satisfy the project manager concerned. Of course as soon as a resource does that, pressure will immediately mount for him to switch back to the original task. If three or more project managers are involved, it is easy to see that a lot of multi-tasking could be going on. Do we have any idea how much time is being wasted through multi-tasking? Just imagine how much time a resource loses every time he or she must re-familiarize himself or herself with what they have already done. The more complex the task the more time is lost. Consider also that these concurrent projects cause all projects to be finished later – focusing on just one would cause it to finish sooner. The sooner a project is finished the sooner it can earn a return. Maybe we have identified an area where time wasted could be reduced.

To get an idea of the impact of multi-tasking try the following:

1. You have 3 projects in parallel. The first is to write the letters of the alphabet in a column. The second is to write the numbers 1 to 26 also in a column. The third is to write the Roman numerals from I to XXVI also in a column.
2. To multi-task, write A, then 1, then I followed by B, 2, II until you reach the end of the alphabet, 26 and XXVI. Don’t forget to measure the time (T1) it takes to complete all three projects.
3. Do the projects again, but this time do it the natural way write A, B, C … Z; followed by the numbers and lastly by the Roman numerals. Again measure the time (T2). T2 will be significantly shorter than T1. The time gained is time that could be used for a fourth project.
4. Note the difference in time and calculate the capacity you could gain by NOT multi-tasking. The formula is: Capacity Gain=(T1-T2)/T2
5. In reality a project organisation may not multi-task this much. However, consider the simplicity of the tasks in these projects and the complexity of tasks in normal projects. Is the impact you have seen reasonable? Consider also the opportunity that might be available.

Ignoring Little’s Law and multi-tasking have a major negative impact on project times and resource effectiveness. As long as organisations cause multi-tasking project managers and task owners must take this into account. In fact few people are actually consciously aware of the impact. However they do have the experience of how long tasks and projects usually take. The adjustment project managers make for multi-tasking is based on experience its “gut feel”.

At this point we do not know how big the opportunity we have. The little experiment is not a real project situation as only 1 resource is involved and the amount of multi-tasking is extremely high. However, as already mentioned, the lost time may be even greater in real projects simply because the ‘set-up’ a resource has to make when returning to a task is much greater. Shouldn’t the project manager population look at the consequences of multi-tasking? Shouldn’t senior management look at their behaviour that causes multi-tasking and maybe reconsider some management behaviour?

<

Technorati Tags: Critical Chain, Execution Management, Prject Execution, Prodct Development, Production, Project, Project Execution, Project Management, Project Manager, Project Plan, Risk Management, Theory of Constraints, TOC

/p>

Technorati Tags: Critical Chain, Execution Management, Prject Execution, Production, Project, Project Execution, Project Management, Project Manager, Project Plan, Risk Management, Theory of Constraints, TOC, Product Development

Technorati Tags: Critical Chain, Execution Management, Prject Execution, Prodct Development, Product Development, Production, Project, Project Execution, Project Management, Project Manager, Project Plan, Risk Management, Theory of Constraints, TOC, Multi Tasking

Project Managers Risk Averse? - Part II (Dec 24, 2010)

A recent (late 2010) “Linkedin” discussion started with: “I was at a live project manager networking event the other night and someone said, ‘Project Managers are Risk adverse by nature.’ Is risk adversion a quality of a successful project manager?” What are they really talking about? The discussion seems to conclude project managers are not anymore risk adverse or averse than any other person. What they do is manage their risk. I thought I would write this article about risk in projects, how risk is planned for (in the project plan) and how risk is managed during project implementation.

2. Risk and Project Planning

Is it safe to assume that project managers are no different than any other manager – they want to have a good career and get ahead in life? Are the three key project deliverables scope, budget and the project due date? If the answer to both questions is YES, then it follows that (almost) every project manager wants to be reliable. He wants to deliver the required scope within the budget on or before the due date.
To ensure reliability has to begin during planning. The plan is the best possible representation of what will eventually happen in reality – or that is what it should be. The project manager must consider all the tasks necessary to complete the project, together with the risks he may well encounter. Not to do so will almost certainly ensure his own and his project’s failure. The experienced project manager knows there are many risks involved with every project – here is an incomplete list:

1. He might miss some important activities that should be included in the project.
2. The client may modify (increase) the project’s scope during execution.
3. There are (many) other projects underway that require the same resources as his project.
4. Project priorities are unclear and are often changed.
5. People (resources) will not always be available when needed (or when promised).
6. There are always surprises with planned activities – they can easily take significantly longer.
7. Authorisations (paperwork) may not be delivered when planned.

Uncertainties may or may not happen – nevertheless they must be considered in the plan. The project manager may or may not be expert in the various activities in a project – often he must rely on the time estimate of the individual (the expert) that will execute an activity. The people that perform an activity have the same goal as their project manager(s), they also want and need to be reliable. The time and cost it will take to execute and deliver (all) the scope determines the value (return on investment) of a project. There is very likely to be pressure on both budget and project time (projects that are too expensive or take too long will not be economical and are likely to be dropped). While management will put pressure on budget and timing, they too need reliability. Too much pressure will jeopardize reliability and their credibility. Project planning seems to be a very difficult task – fraught with risk!
What is the shape of risk? For every task there is some sort of minimum time – the task cannot ever be completed more quickly than that. There is also a most likely time around which the task would be finished most of the time (would we be able to execute it many times). There is no maximum – a big enough disaster, while unlikely, can occur so that a task is never finished (think of the roof of the Montreal Olympic stadium – it was completed something like 16 years after the Olympics there). The probability curve of a task is a skewed curve – with a long tail to the right. The situation looks like the graphic above.

The importance of the curve is that it shows how much safety a resource must build into his time estimate in order to be 85% certain of finishing on time. (The curve will always have

this general shape though the amount of skew to the right will vary.)

Each task is estimated so that the resource concerned (and the project manager) feels reasonably certain that the task can be delivered within the

estimated time. Task times will be set with 80 – 90% chance of finishing within the set time. The logic is described in the graphic below (you read the entities from the bottom up). It looks like each task should have at least an 80-90% chance of finishing on time. If every task does finish on time, then

clearly the project will also

finish on time. Isn’t this what actually happens – every resource (and every project manager) includes enough time in every task so that he can be quite certain all (the vast majority) of tasks are actually completed within the estimated time.

I am quite sure that a large section of the project manager population and also task owners will be disturbed by the logic above. They must claim that estimates are much closer to the 50:50 chance of finishing on time. Their experience tells them that estimates are almost always insufficient – many projects have great difficulty finishing on time, on budget and with scope intact. Therefore a project manager’s task and project time estimates must include a lot of risk! Estimates are no better than 50:50 – at least that is the belief.

What is the truth? Are project managers people that manage risk appropriately – e.g. they create plans they believe they will meet with a high degree of certainty, or are they (mad) risk takers that produce task and project time estimates that are clearly unrealistic? Maybe the evidence should be checked! (I assume actions that can be taken to mitigate risk are implemented – this reduces risk, but cannot eliminate it – a part of risk management will always be to plan for ‘Murphy’).

There are plenty of reports that show that a high proportion of projects are delivered late. If this is true, then either project due dates are wildly

optimistic or, if task time estimates are realistic, then most tasks are finished within the time set for them and it takes just those few delayed tasks that cause a project to be late (or very late). This last sentence could be true if the majority of tasks finish on their due date (or very close to it)

and very rarely early. Check your task statistics. You should see that the vast majority complete on or near their due date (or they take the elapsed time given) and a few will be late or very late. If this is so, then the skewed curve above is not correct – there is something that is causing a huge spike on the due date with very few early finishes and a significant enough number of delays to cause many projects to be late.

If you can confirm that most tasks do finish on time - either because you or your company measure this performance or simply because that is your experience - please let us know. If most tasks are on time then the important question becomes,'why are so many projects late - or have great difficulty in finishing on time?'

Project Managers Risk Averse? - Part I (Dec 24, 2010)

 

A recent (late 2010) “Linkedin” discussion started with: “I was at a live project manager networking event the other night and someone said, ‘Project Managers are Risk adverse by nature.’ Is risk adversion a quality of a successful project manager?” What are they really talking about? The discussion seems to conclude project managers are not anymore risk adverse or averse than any other person. What they do is manage their risk. I thought I would write this article about risk in projects, how risk is planned for (in the project plan) and how risk is managed during project implementation.

1. Definitions

Averse is an adjective meaning to have a strong feeling of opposition, antipathy, repugnance, etc. against something; opposed: He is averse to drinking and driving now.

Adverse is an adjective meaning :

1. unfavorable or antagonistic in purpose or effect: adverse criticism.
2. opposing one's interests or desire: adverse circumstances.
3. being or acting in a contrary direction; opposed or opposing: adverse winds.
4. opposite; confronting: the adverse page.

Isn’t the discussion a reflection of the fact that projects always have some level of risk involved because projects are one of a kind? Don’t projects range from those that are fairly predictable because they are at least similar to projects already completed to projects in which practically everything is unknown? A research and development project is likely to be considerably more uncertain than building a new house that is a copy of many that have been built before. Nevertheless the project manager for a house project still has to consider a number of uncertainties – will resources be on site when he needs them, will the weather behave nicely, will supplies arrive on time, what mistakes will be made, etc. etc. Risk is always present.

That risk is always present is nothing new; so why the discussion about project managers being risk adverse or risk averse? In the end it does not matter whether project managers are or are not – one way or another they must deal with risks. They are managers of risk (as is any other type of business manager) when project managers plan their project and later on during execution (unfortunately even a very good plan does not guarantee nothing will go wrong). Isn’t the most important part of the project manager’s job how he deals with (manages) uncertainty (Murphy) during execution? After all Murphy’s Law states that, “what can go wrong will go wrong.”

Part II follows shortly.

 

Technorati Tags: Project, Project Management, Risk Management, Project Manager, Project Plan, Prject Execution, Execution Management, TOC, Theory of Constraints, Critical Chain

Technorati Tags: Critical Chain, Execution Management, Project, Project Management, Project Manager, Project Plan, Risk Management, Theory of Constraints, TOC, Project Execution

MfA Make for Availability TheoryOfConstraints

Technorati Tags: Execution Management, Theory of Constraints, TOC, Supply Chain, Make to Stock, MTS, Inventory Management, Inventory, Production, Availability

Technorati Tags: Availability, Execution Management, Inventory, Inventory Management, Make to Stock, MTS, Production, Risk Management, Supply Chain, Theory of Constraints, TOC

Business Process Design

 

What is key to a business process?

The Key to Success

What is the goal of a business? Let us assume it is to make money – probably the goal of the majority of businesses around the World. Of course it is possible that the owners of a business choose another goal – such as the happiness of their employees or the satisfaction of their customers. It does not matter which goal the owners happen to choose it is essential to make enough money to support (or deliver) the chosen goal.

So, to make money is essential and can be either the goal or the surrogate for or goal.

The question then becomes, “How are we going to make money? Which of the business processes is the one that will deliver the money we need to fulfil the goal?” Finance (in companies that produce a product) is not the key process – it measures and it should control, but it does not deliver the profit.

I submit that operations – the processes that develop the product, produce the product and deliver it to customers are the ones key for success. The product itself, while important, also is not the key – it is the process of developing new and better products that counts. The product however tells us that the customer is the primary target – product development, production and distribution are all processes that should satisfy your clients’ needs – so that he buys, and then buys again and again.

A business should focus first on one of product development, production and distribution – all three to be eventually designed to maximize profits and profitability.

Product Development, Production and Distribution

The product itself and its quality are certainly essential to the success of any business. However, please first consider how a company achieves an advantage through the products it sells – most companies in a market segment have more or less equal products – companies often compete on price simply because the difference to other competitors is too small for the consumer or buyer to recognise a difference.

In product development a difference can be achieved by the ability to deliver more new developments faster and more reliably than the competition. There is a methodology that can help a company achieve reliability, speed and capacity. It is Critical Chain – project management the Theory of Constraints way. Many companies have shown that 90%+ reliability, 25-50% shorter lead time and 25 -50% capacity gains from the same resources are all possible – at the same time. Critical Chain chains the project management process in a way that reduces the time wasters found in almost all traditional project organisations. The key is the change to the way the company manages projects.

Production is analogous to projects – a project plan looks like the ‘routing’ network in production. The difference is that in production a unit of production waits in a queue relatively even more than a project does. In many production environments the product is in a queue (and not being worked on) well over 90% of the time and often over 99% of the time. Products wait in queues because so much is underway and machines cannot be instantly available. Drum Buffer Rope and Simplified Drum Buffer Rope (Production the Theory of Constraints way) both focus their attention on the limiting factor of a factory, increase the rate of flow through the factory and deal actively with the system’s uncertainties so that lead-times can be cut in half, WIP inventory can be cut similarly and because production priorities are clear, much less time is lost at the capacity critical machines. As in projects the factory realizes reliability, speed and capacity increases. Again, the key is to change the way the company manages production.

Distribution is somewhat different.  If the company and/or their clients stock the company’s products in order to be able to deliver quickly then the amount of cash tied up in stock and a high level of availability are both critical to the client. In many environments the result is a compromise that results in too high stock levels and inadequate product availability. Distribution the Theory of Constraints way goes a long way to solving the problem. Inventories can often be cut by 50% while availability increases to over 95%. (In retail businesses shelf space can be used more effectively.) The key is to change the way the distribution network is replenished and therefore the way production is planned and scheduled.

To gain significant and decisive competitive advantages in these three operations areas a significant change to their processes is essential. The solutions are common sense, but certainly not common practice.

Re-engineering the Operations Processes

If a company wants to (re-) engineer their operations, then it is essential to first define the goal they want to achieve and how they intend to achieve that goal. If reliability, speed and capacity (that lead to much greater profit and profitability) are key elements of the desired outcome then the new processes must b designed to do that. Implementing what is common practice may well result in a company that is well placed within its industry, but it will not lead to a decisive competitive edge and rapid success.

It is possible to re-engineer a company and then later on do the job again to achieve the kind of results described above. However, this seems a waste of time and will likely be confusing and frustrating for the company’s personnel. This is especially so because the processes described above are by far simpler to understand and implement than most of the rather complex existing methodologies. There is in fact a dilemma here, either we implement what is commonly accepted practice in industry or we implement something new and unique.

A business wishing to (re-) engineer their processes has a choice to make. They can either:

A. Introduce business processes that are the same as common practice throughout industry. This seems to be the safe option since these processes have been proven by many businesses to be good enough. Even most successful businesses use processes that are common practice. A business that introduces processes that are common practice cannot be making a mistake.

B. Introduce business processes that are new and unique at least in some way. New and unique processes introduce the possibility of competitive advantage – because they are different – although being different does not guarantee an advantage. In fact the opposite can be true.

The business that chooses option A almost guarantees that it will not develop a significant competitive advantage. As long as no other competitor chooses option B it may continue to earn a (satisfactory) return. However, what seems to be the safe option can easily turn out to be very risky indeed – it takes just one competitor to either launch a price war or, even worse, change his business processes to gain a competitive advantage.

The business that chooses option B has already understood that A cannot be a winning solution. However a company that chooses option B must choose carefully to select something new that is not too risky and that its competitors will not be able to copy easily. The recommendations above are not proof that these approaches are risk free. It is up to the company to evaluate how risk these options really are.

The recommendation made here does NOT preclude the use of Lean and/or 6-Sigma. Both these tools and methods are important and strengthen the recommendations made above. Companies that use all 3 appropriately report superb results. Do not disregard these very useful tools!

 

Technorati Tags: Production, Strategy and Tactics, Prodct Development

Technorati Tags: Inventory, Inventory Management, Prodct Development, Production, Risk Management, Strategy and Tactics, Supply Chain, Theory of Constraints, TOC, Distribution