Вовремя и в рамках бюджета - Лоуренс Лич 11 стр.

Во-вторых, любую управленческую теорию можно рассматривать через призму системы глубинных знаний Деминга.

В данной главе показано, как совместное использование четырех управленческих концепций помогает совершенствовать систему управления проектами в целом. Эти концепции значительно пересекаются между собой, и в них практически нет расхождений по основополагающим принципам и ценностным установкам. Надеюсь, прочитав вторую главу, вы тоже теперь видите, что:

• РМВОК дает полное описание проектной системы (существующей теории);

• принципы и приемы ТОС позволяют усовершенствовать теорию;

• концепции бережливого производства и шести сигм подсказывают, как лучше приложить ТОС к положениям РМВОК ;

• бережливое производство, шесть сигм и ТОС используют принципы системы глубинных знаний Деминга: понимание системы, вариабельности, теории познания и психологии;

• в РМВОК и большей части специализированной литературы не делается различий между общими и особыми причинами вариаций. Поскольку производственная и проектная системы похожи (глава

1) и поскольку ТОС позволяет значительно улучшить работу производственных систем, то в применении к проектам ТОС также может помочь избавиться от существующих нежелательных явлений;

• ТОС предлагает логический процесс совершенствования систем путем определения «что менять», «на что менять», «как осуществить перемены»;

• пять направляющих шагов ТОС описывают этапы реализации процесса совершенствования: найти ограничение, максимально использовать мощность ограничения, подчинить всю работу нуждам и ритмам ограничения, снять ограничение, не позволять инерции вставать на пути дальнейших преобразований;

• чтобы совершенствовать проектную систему, необходимо сначала найти ограничение (ключевой конфликт), лежащее в основе НЯ существующей проектной системы (или существующей теории); ключевой конфликт покажет, что нужно менять;

• процесс логических рассуждений по ТОС позволяет сконструировать новую систему, то есть показывает «на что менять»;

• методики управления изменениями необходимы, чтобы вызвать перемены в привычном поведении, без которых не достичь всего, что может дать ССРМ.

В главе 1 была сформулирована проблема, а в главе 2 дан обзор теоретической базы, теперь мы подошли к этапу разработки улучшенной теории планирования и управления проектами. ТОС содержит стратегию использования приемов бережливого производства и шести сигм в этих целях.

1. PMI, A Guide to the Project Management Body of Knowledge, Newton Square, PA: PMI, 2000 (в русском переводе: Руководство к своду знаний по управлению проектами/Под. ред. В. Либерзона, Д. Лобанова. — М.: Институт управления проектами, 2004. — редакция 2000 года; Руководство к своду знаний по управлению проектами. — Project Management Institute, 2004. — редакция 2004 года).

2. PMI, Organizational Project Management Maturity Model Knowledge Foundation, Newton Square, PA: PMI, 2003.

3. Carnegie Mellon University, The Capability Maturity Model: Guidelines for Improving the Software Process, Reading, MA: Addison-Wesley, 1994.

4. Womack, J., D.Jones, and D.Roos, The Machine That Changed the World: The Story of Lean Production, New York; HarperCollins Publishers, 1990 (в русском переводе: Вумек Д., Джонс Д., Рус Д. Машина, которая изменила мир. — М.: Попурри, 2007).

5. Womack J., and D.Jones, Lean Thinking: Banish Waste and Create Wealth in Your Corporation, New York: Simon & Shuster, 1996 (в русском переводе: Вумек Д., Джонс Д. Бережливое производство. Как избавиться от потерь и добиться процветания вашей компании. — М.: Альпина Бизнес Букс, 2004).

6. Dettmer, W., Beyond Lean Manufacturing: Combining Lean and the Theory of Constraints for Higher Performance, 2000, доступна по адресу http://www.goalsys. com/HTMLobj-786/TOC_and_Lean_Paper Dettmer-rev_.pdf (материал для книги взят 30 апреля 2004 г.).

7. Wikipedia, “Agile software development”, доступна по адресу http://en.wikipedia. org/wiki/Agile_Methods (материал для книги взят 21 июня 2004 года).

8. Anderson, David J., Agile Management for Software Engineering, Upper Saddle River, NJ: Prentice Hall, 2003.

9. NIST, Baldrige, Six Sigma, & ISO: Understanding Your Options, 2002, доступна на http://www.quality.nist.gov/PDF_files/Issue_Sheet_SS.pdf (материал для книги взят 30 апреля 2004 года).

10. Pande, P., R.Neuman, and R. Cavanagh, The Six Sigma Way: How GE, Motorola, and Other Top Companies Are Honing Their Performance, New York: McGraw-Hill, 2000.

11. Hendricks, Kevin B., and Vonid R. Singhal, “Don’t Count TQM Out. Evidence Shows Implementation Pays Off in a Big Way”, Quality Progress, April 1999.

12. Deming, W.Edwards, Out of the Crisis, Cambridge, MA: MIT Press, 1982 (в русском переводе: Деминг Э. Выход из кризиса. Новая парадигма управления людьми, системами и процессами. — М.: Альпина Бизнес Букс, 2007).

13. Deming, W. Edwards, The New Economics, Cambridge, MA: MIT Press, 1993 (в русском переводе: Деминг У. Эдвардс. Новая экономика. — М.: Эксмо, 2006).

14. Senge, Peter, The Fifth Discipline, New York: Doubleday, 1990 (в русском переводе: Сенге П. Пятая дисциплина. Искусство и практика самообучающейся организации. — М.: Олимп-Бизнес, 2003).

15. Brooks, Frederick P., The Mythical Man Month: Essays on Software Engineering, Reading, MA: Adison-Wesley, 1995 (в русском переводе: Брукс Ф. Мифический человеко-месяц, или Как создаются программные системы. — Спб.: Символ-Плюс, 2006).

16. Hardin, Garret, Filters against Folly, New York: Viking, 1985.

17. Popper, Karl R., Objective Knowledge, An Evolutionary Approach, Oxford: Clarendon Press, 1979 (в русском переводе: Поппер К.Р. Объективное знание. Эволюционный подход. — М.: Эдиториал УРСС, 2002).

18. Shewhart, Walter A., Statistical Method, New York: Dover, 1986.

19. Skinner, B.F., Science and Human Behavior, London: The Free Press, Collier Macmillan, 1953.

20. Kohn, Alfie, Punished by Rewards, Boston: Houghton Mifflin, 1993.

21. Herzberg, Frederick, Work and the Nature of Man, Cleveland, OH: World Publishing, 1966.

22. Goldratt, Eliyahu M., Theory of Constraints, Croton-on-Hudson, NY: North River Press, 1990.

23. Dettmer, H. William, Eliyahu M. Goldratt’s Theory of Constraints, A Systems Approach to Continuous Improvement, Milwaukee, Wisconsin: ASQC Press, 1997 (в русском переводе: Детмер У. Теория ограничений Голдратта: Системный подход к непрерывному совершенствованию. — М.: Альпина Бизнес Букс, 2007).

24. Goldratt, Eliyahu M., The Goal, Great Barrington, MA: North River Press, 1984 (в русском переводе: Голдратт Э. М., Кокс Д. Цель. Процесс непрерывного совершенствования. — М.: Попурри, 2007).

25. Goldratt, Eliyahu M., It’s not Luck, Great Barrington, MA: North River Press, 1994 (в русском переводе: Голдратт Э. М., Кокс Д. Цель. Процесс непрерывного улучшения. Цель-2. Дело не в везенье. — Киев—Москва: Максимум, Логос, 2007).

26. Noreen, Eric, Debra Smith, and James T. Mackey, The Theory of Constraints and Its Implications for Management Accounting, Great Barrington, MA: North River Press, 1995.

27. Braksick, L. Unlock Behavior, Unleash Profits, New York: McGraw-Hill, 2000.

28. Kotter, J. “Leading Change: Why Transformation Efforts Fail.” In Harvard Business Review on Change, Boston, MA: Harvard Business Review Publishing, 1998, рр. 1-20 (в русском переводе: Коттер Д. П. Впереди перемен. — М.: Олимп-Бизнес, 2007).

Глава 3. Выбираем подход к решению

Что менять — вот самое важное решение, которое вы принимаете, задавшись целью что-либо улучшить. Из этого следует все остальное. Если вы решаете изменить то, что не является ограничением, скорее всего, вы никак не повлияете на систему. А может быть, положение дел даже ухудшится, если в итоге появится новое ограничение, еще более мощное, чем имевшееся прежде. Но уж точно вам никогда не добиться положительных изменений, работая над не-ограничением.

За годы работы мне приходилось сталкиваться с десятками компаний, пытавшихся добиться улучшения итоговых показателей путем реорганизации. Ни у одной из них ничего не вышло. Также я наблюдал ряд попыток совершенствовать управление проектами при помощи внедрения нового программного обеспечения, увеличения объема тренингов и разработки процедур, но и они не привели к заметному росту показателей. Во всех этих случаях производились материальные изменения: добавлялись «квадратики» в организационную структуру, проводилось обучение, закупались (а иногда даже использовались) компьютерные программы, писались тома процедур — однако уровень результативности проектов оставался неизменным. Ну и, конечно, менялось руководство. Как объясняет ТОС, все это говорит лишь об одном: предложенное решение не позволило максимально использовать возможности ограничения системы. Единственный положительный опыт перемен, имевшийся у меня еще до знакомства с ТОС, как выяснилось при ближайшем рассмотрении, был связан с ситуацией, когда усилия направлялись на ограничение. Тогда сработали многие принципы ССРМ. Люди, проводившие преобразования, не знали теории, лежащей в основе ССРМ. Если бы они ее знали, изменения были бы еще более успешными.

И теперь, став свидетелем использования ССРМ во множестве организаций, могу объяснить, как это работает.

Цель системы управления проектом заключается в том, чтобы обеспечить достижение результатов, удовлетворяющих всех участников проекта. Для этого необходимо выполнить проектное задание (обещанный объем работ) в оговоренный срок или досрочно при заранее определенном или меньшем уровне затрат. Схематичное изображение проектной системы как «черного ящика» на рис. 3.1 показывает цель, входы и выходы и подсказывает, какие необходимы измерения для контроля за системой на пути к достижению цели.

Чтобы улучшить систему управления проектом, согласно теории познания, необходимо определиться с проблемами, которые заложены в существующей системе. Сравнение прогнозов, сделанных с помощью существующей проектной системы (теории), с реальностью помогает установить такие проблемы. Наблюдая возникающие при работе системы нежелательные явления (НЯ), мы естественным образом сможем определить существующие в системе проблемы и понять, каких желаемых результатов (ЖР) нам необходимо добиться, чтобы говорить об улучшении проектной системы как таковой. В главе 1 были определены следующие НЯ:

Цель системы управления проектом заключается в том, чтобы обеспечить достижение результатов, удовлетворяющих всех участников проекта. Для этого необходимо выполнить проектное задание (обещанный объем работ) в оговоренный срок или досрочно при заранее определенном или меньшем уровне затрат. Схематичное изображение проектной системы как «черного ящика» на рис. 3.1 показывает цель, входы и выходы и подсказывает, какие необходимы измерения для контроля за системой на пути к достижению цели.

Чтобы улучшить систему управления проектом, согласно теории познания, необходимо определиться с проблемами, которые заложены в существующей системе. Сравнение прогнозов, сделанных с помощью существующей проектной системы (теории), с реальностью помогает установить такие проблемы. Наблюдая возникающие при работе системы нежелательные явления (НЯ), мы естественным образом сможем определить существующие в системе проблемы и понять, каких желаемых результатов (ЖР) нам необходимо добиться, чтобы говорить об улучшении проектной системы как таковой. В главе 1 были определены следующие НЯ:

1. Проекты часто идут с нарушением графика.

2. Проекты часто идут с превышением бюджета.

3. Чтобы уложиться в срок и в бюджет, часто приходится жертвовать содержанием проекта.

4. В проектах происходит слишком много изменений.

5. В компаниях, где одновременно реализуется множество проектов, часто идет борьба за ресурсы.

6. Длительность проектов все растет.

7. Многие проекты останавливаются, не дойдя до цели.

8. Проектные работы оказывают серьезное давление на большинство участников.

Нежелательные явления — это то, что нам не нравится в существующей системе. Хороший способ проверить, что перед нами действительно НЯ, — сформулировать предложение типа «Меня действительно беспокоит то, что.». Ваш список НЯ может включать в себя какие-то иные пункты, чем вышеперечисленные. Если нужно, дополняйте или сокращайте приведенный перечень.

ТОС помогает нам понять, что все эти явления — непосредственный продукт работы проектной системы, в которой мы в данный момент находимся. Хотя это и не преднамеренные результаты, их стабильное присутствие свидетельствует о том, что они — прямое следствие действия системы. Значит, где-то в системе есть нечто, вызывающее появление этих НЯ. Ввиду того, что нежелательные явления наблюдаются в любых типах проектов во всех сферах бизнеса и в разных видах культур, мы можем сделать вывод, что тип проекта, бизнеса и культуры не является первоочередным фактором или воздействием, вызывающим появление таких результатов. ТОС подводит нас к мысли, что НЯ — это следствие некоего глубинного конфликта или дилеммы, универсальных для любого окружения. Чтобы определить, что менять, необходимо выявить эту дилемму — ограничение существующей системы.

Как утверждается в главе 1, любой стоящий проект стоит делать быстро. Причина в том, что инвестирование в большинство проектов начинается с самого их запуска, однако окупаться эти инвестиции начнут только тогда, когда проект будет реализован. Таким образом, цель уже начатого проекта — завершить его как можно быстрее. Рассмотрим, что является ограничением для достижения данной цели.

В большинстве реализуемых сегодня проектов используется метод критического пути СРМ, разработанный в начале 1950-х и являющийся «гвоздем» большинства учебных программ по управлению проектами. (Я знаю, о чем говорю. Сам веду некоторые из них в Университете Феникса). Он же описан и во всех работах по управлению проектами. На рис. 3.2 показан типичный график, построенный методом критического пути. Самый длинный путь в диаграмме — критический путь.

Рис. 3.2 также показывает ресурсы, назначенные на выполнение каждой операции. Предположим, при оценке длительности операции учитывалось, что исполнитель будет заниматься только данной работой (рекомендую такой подход по причинам, которые станут ясны чуть позже). Завершится ли данный проект вовремя? Вряд ли. По графику исполнители должны будут выполнять одновременно несколько операций («многозадачность»). Поэтому длительность каждой отдельной операции и, значит, всего проекта увеличится. А поскольку проект завершается с опозданием, если хотя бы одна операция на критическом пути будет выполнена позже срока, следовательно, данный проект спланирован так, что срыв плановой даты неизбежен. И это справедливо практически для всех проектов, планируемых методом критического пути, поскольку почти ни в одном из них не используются безграничные ресурсы.

Анализ проекта на рис. 3.2 позволяет прикинуть, сколько времени он на самом деле займет. Рассмотрим работу исполнителя 1 (операции 1, 3 и 5). Начало всех этих операций запланировано на одну и ту же дату, значит, каждая операция будет длится втрое дольше, поскольку все они должны выполняться одновременно. Таким образом, самая короткая операция 1 длительностью 5 дней завершится через 15 дней, а задания 3 и 5 будут выполнены на этот момент настолько, сколько можно сделать за 5 дней. Теперь исполнитель 1 должен будет распределять время между двумя оставшимися операциями, при этом из 2 дней работы по проекту на каждую будет уходить по 1 дню. Следовательно, оставшиеся 20 дней операции 3 выльются на деле в 40 дней и общая ее продолжительность составит 55 дней. Через 55 дней по заданию 5 еще останется сделать работы на 25 дней, и длительность ее в совокупности окажется 80 дней.

Расчет по исполнителю 2 более сложен ввиду взаимосвязанности операций. На 15-й день исполнитель 2 может начать работу по заданию 2 и посвящать ему 100% времени. Он не сможет приступить к операции 4, пока исполнитель 1 не завершит задание 3 (то есть не раньше дня 55). Таким образом, исполнитель 2 может полностью заниматься операцией 2 в течение 40 дней, однако последние 5 дней уже придется выполнять и задание 4, поэтому общая длительность операции 2 вырастет до 50 дней. Операция 4 теперь пересекается с задачами 2 и 6 и вырастает до 40 дней. На рис. 3.3 представлена схема ожидаемой фактической реализации проекта с датой окончания, сдвинувшейся более чем на месяц. Проект был обречен.

Существует метод решения данной проблемы — это выравнивание ресурсов. Большинство программных продуктов, основанных на методе СРМ, предлагают такую возможность. Рис. 3.4 — вариант графика с рисунка 3.1, к которому было применено выравнивание ресурсов. Обратите внимание: дата завершения плана-графика с выравненными ресурсами совпадает с датой, полученной на графике фактической реализации. Этот метод также устраняет первое нежелательное явление — частое нарушение графика. Еще бы, ведь для этого он и создан!

Рассматривая рис. 3.2 и 3.4, можно сделать интересное наблюдение. Компьютерная программа включила в критический путь только операции 5 и 6. Странно, что в критический путь не попали операции, идущие перед ними. Почему программа выбрала именно эти операции, для меня загадка. И я знаю, что после выравнивания ресурсов при помощи другой программы получится совсем иной критический путь, пусть даже выравнивание будет произведено одинаковым образом. Причина в том, что критический путь не определяется после выравнивания. До выравнивания в него не включен временной резерв («float», он же «slack»). Обратите внимание, что на рис. 3.2 у обоих некритических путей (операции 1 и 2 и операции 3 и 4) есть такой резерв, отмеченный чертой, продолжающейся справа от операции. После выравнивания ресурсов (рис. 3.4) резерв есть по всем операциям. Таким образом, ни одна из них не составляет критический путь.

На своих занятиях в PMI я устраиваю неофициальное исследование. Я спрашиваю, сколько студентов в планах своих проектов указывают загрузку по ресурсам (то есть обозначают, какие ресурсы назначены на выполнение каких операций, как на рис. 3.2). Обычно это от половины до двух третей слушателей. Затем я спрашиваю, кто из них проводит выравнивание ресурсов. Обычно таковых около 5%. Получается, что примерно 95% проектов уже с самого начала обречены на провал. Не забывайте, что я опрашивал элиту управления проектами, большинство из них — сертифицированные профессионалы РМР.

Тем, кто назначает, но не выравнивает ресурсы, я задаю вопрос о причинах подобного поведения. Большинство не находятся с ответом, а те, кто все же отвечает, обычно говорят одно из двух:

1. Тогда сдвигается дата окончания проекта (!).

2. Выравнивание влечет за собой действия, лишенные всякого смысла.

Первый ответ указывает на нежелание взглянуть в лицо реальности. О втором поговорим позднее.

Сейчас мы вслед за доктором Элияху Голдраттом введем небольшое изменение в определение: ограничением в отдельно взятом проекте является критическая цепь, которая выявляется как самый длинный путь в сетевом графике после выравнивания ресурсов. Рис. 3.5 показывает критическую цепь в простом проекте, взятом нами за пример. Обратите внимание: на стадии определения в ней нет временного резерва. Также отметьте, что она «прыгает» по логически связанным цепочкам задач в проекте (хотя технически логика всего плана остается неизменной).