In this article, you’ll learn the fundamental elements of a strategic implementation process, and how you can create a comprehensive implementation plan. We’ve also included free, downloadable implementation plan templates to get you started.
Included on this page, you’ll find the components of an implementation plan, how to write an implementation plan, and tools for successful implementation planning.
What Is an Implementation Strategy?
An implementation strategy is based on a strategic plan, which defines the strategy used to accomplish certain goals or make decisions. Organizations can make strategic plans to guide organizational direction, a particular department’s efforts, or any project or initiative.
Implementation strategy is the process of defining how to bring the strategic plan to life. To execute the objectives outlined in the strategic plan, you must define how you will implement each aspect, from funding and personnel to organization and deliverables. Therefore, without an implementation strategy, it can be difficult to identify how you will achieve each of your stated goals and objectives.
See how Smartsheet can help you be more effective
Watch the demo to see how you can more effectively manage your team, projects, and processes with real-time work management in Smartsheet.
Watch a free demo
What Is the Strategic Implementation Process?
The strategic implementation process refers to the concrete steps that you take to turn your strategic plan into action. The implementation tactics you use and steps you take will depend on the specific undertaking, organization, and goals.
A strategic implementation plan (SIP) is the document that you use to define your implementation strategy. Typically, it outlines the resources, assumptions, short- and long-term outcomes, roles and responsibilities, and budget. (Later on, we’ll show you how to create one.) An SIP is often integrated with an execution plan, but the two are distinct.
The SIP outlines the activities and decisions necessary to turn the strategic goals into reality, and the execution plan is a schedule of concrete actions and activities to achieve goals and drive success. You can consider your strategy “implemented” once you determine that you have the requisite resources to meet your strategic needs, but you haven’t “executed” until you’ve actually taken action and achieved objectives. You can read more about the differences between strategy, implementation, and execution in this article by the Harvard Business Review.
The strategic implementation process is often compared to the following activities:
- Organizational Planning: Also called organizational design or organizational structure, this is the high-level process of identifying an organization’s general operational goals and then building specific strategies to meet them. While strategic planning centers on evaluating an existing organization’s strengths and weaknesses and identifying specific goals for improvement, organizational planning is more concerned with how specific tasks, processes, and decisions will flow within the organization.
Like implementation planning, organizational planning also requires you to create a plan of action. You can use a template to ease the process of writing this complicated plan. Throughout this article, you’ll find other free, downloadable templates for a variety of different planning activities.
Download Organizational Change Management Plan
- Strategic Management Process: This is the ongoing effort to manage an organization, including both the decisions and actions that flow from the organizational strategy. Continuous strategic management can inform organizational planning by providing a strategy that outlines the organization’s goals.
- Change Management: Change management is how you prepare and manage organizational planning, from the high-level processes and culture down to individual roles. Effective change management involves strategy and careful monitoring so that you can plan for change rather than react to it.
Download Change Management Process Template
Word | PDF
- Differentiated Planning: This is a reordering method that you can use to identify which resources you need based on the frequency with which you typically use them. Separate the items on your reorder list into three categories: routine, regular, and rare. This will give you a rough idea of the different demand levels for each resource, so you don’t have to spend time considering whether or not to restock. Because identifying and accumulating resources is an important component of implementation planning, it’s useful to understand differentiated planning.
Why Implementation Is Important
Implementation planning largely determines project success because without it, your strategic goals remain unactionable. Therefore, implementation is the necessary step that transforms your strategic plans into action to achieve your goals.
There are many examples where implementation planning heightens project success. In fact, the Harvard Business Review reported that companies with an implementation and execution plan saw 70 percent greater returns.
McKenzie says that implementation planning is critical to project success. “This is the stage which allows the planned strategy to be executed,” he says. “The primary benefits to implementation and implementation planning are the abilities to outline the tasks needed to complete the project, identify the personnel and resources needed, and document the timeline for project completion to ensure you’re meeting the strategic goals.”
Hancock agrees. “If you don’t implement your plan — you don’t get anything done,” she says. “So, implementation is crucial. [Even] if you have the best plan in the world, it’s totally irrelevant if you don’t put the plan into action,” she adds.
The practice of implementation planning is also important in some of today’s organizational shifts. Most notably, implementation plays a part in the current shift from reactionary to strategic companies — in other words, organizations that plan for change and adaptation rather than react to it. Additionally, implementation supports the movement toward employee-oriented organizations, which it does by valuing communication, encouraging mutually-supported goals, and emphasizing accountability. Implementation planning is necessarily a human (and team) endeavor and making it a part of your daily processes helps ensure collaboration, trust, and transparency among project team members all the way up to C-suite management.
What Is the Implementation Plan of a Project?
Implementation plans are commonly used for discrete projects, technology deployment within a company, and inventory planning. You can also create an implementation plan for personal use if it will help you organize and take actionable steps toward your goal(s).
A project implementation plan is the plan that you create to successfully move your project plan into action. This document identifies your goals and objectives (both short and long-term), lists the project tasks, defines roles and responsibilities, outlines the budget and necessary resources, and lists any assumptions. A project implementation plan sometimes includes a rough schedule, but teams usually set the hard timeline in the execution plan.
In the following sections, we’ll delve deeper into each component of an implementation plan and show you how to write your own.
Components of an Implementation Plan
The following are the key components of and questions that drive a successful implementation plan:
- Define Goals/Objectives: What do you want to accomplish? The scope of these goals will depend on the size of your undertaking.
- Schedule Milestones: While task deadlines and project timelines will be formally set in the execution plan, it’s a good idea to outline your schedule in the implementation phase.
- Allocate Resources: One of the core purposes of an implementation plan is to ensure that you have adequate resources (time, money, and personnel) to successfully execute. So, gather all the data and information you need to determine whether or not you have sufficient resources, and decide how you will procure what’s missing.
- Designate Team Member Responsibilities: Assign roles. This doesn’t necessarily mean you must define who will execute each individual task, but you should create a general team plan with overall roles that each team member will play.
- Define Metrics for Success: How will you determine whether or not you are successful? What data (whether quantitative or qualitative) will you use to measure your results, and how will you accrue the necessary data?
- Define How You Will Adapt: Make a plan for how you will adapt, if necessary, to changes in your plan. Be sure to consider factors outside your control that could significantly alter the schedule or success of your project, and create emergent strategies ahead of time, so you don’t get derailed down the road — doing so helps build a culture of flexibility, agility, and fast action.
- Evaluate Success: In addition to defining your metrics for success, decide how often you will evaluate your progress (e.g., quarterly reviews).
In the following section, we’ll break down each element of a successful implementation plan to show you how to write one yourself.
How to Write an Implementation Plan
Implementation plans are split into sections. Each section should be detailed, combining the information from your strategic plan and incorporating the necessary research and data to make your objectives actionable. Here’s how to write each component in an implementation plan:
- Introduction: The introduction of your implementation plan explains the purpose, vision, and mission statement of your project or initiative. You should identify the high-level risk areas, include any assumptions, and describe how you will identify the value stream in your proposed work.
- Management Overview: In this section, you describe how implementation will be managed. This includes who is managing it, the underlying roles and responsibilities, and key points of contact. You should identify the strategy director, who is the person that develops and steers the strategy (this may or not be the same person who is leading implementation).
- Major Tasks: This is where you list and describe the specific tasks, actions, and targets in implementation. You should also note the status of any tasks that are already in progress.
- Implementation Schedule: You do not need to create a detailed, inflexible task schedule in your implementation plan — we’ll talk later on about how to create a schedule in the execution plan. At this stage, it’s appropriate to simply list the task order and predicted phase durations to roughly outline and allot for all the many moving pieces.
- Security and Privacy: Discuss the privacy features and considerations of the software tools, processes, or information that you may use in implementation. Address security issues and how to handle sensitive information (personal data, medical history, financials, etc.).
- Implementation Support/Resources List: Describe the various tools, activities, and departments that you require to support successful implementation. These might include hardware or software tools, facilities, and additional external human resources or services.
- Documentation: In this section, you must attach any other documentation that supports your implementation plan. This could include your strategic plan, confirmation of adequate materials and resources, and a history of past successful projects.
- Monitoring Performance: Define the metrics by which you will measure success. How and when will you review your progress?
- Acceptance Criteria: How will you define implementation “completion?” This differs from performance monitoring because rather than defining metrics for milestones and appropriate implementation, here, you describe how you will know when you have buy-in from management on your implementation plan.
- Glossary: Define any key terms used in your implementation plan.
- References: Indicate where you received your information, or list people who support your plan.
- Project Approval: If you need management’s approval before moving into execution, this section provides space for official signoff.
To make it easy, you can also use a template to write your implementation plan. This will ensure that you don’t overlook any steps or sections and also provide a professional layout that you can use to deliver to management, clients, or other stakeholders. Download the template for free, and edit the fields to fit the needs of your specific project — for example, for enterprise resource planning (ERP).
Download Project Implementation Plan Template – Word
Software deployment is another common category of initiative that merits an implementation plan. Use the following template to create a software and systems implementation plan.
Download Software Systems Implementation Plan Template – Word
Implementation Planning Best Practices
Although you should include all the detailed aspects listed above in your implementation plan, simply having all these components will not ensure success. Instead, you should focus on the process of implementation and foster the following behaviors within your team:
- Create a Designated Implementation Team: An implementation team is the team responsible for ensuring successful implementation of a particular initiative. While it’s possible to move through implementation without creating a specific, organized body to oversee the processes, doing so heightens your chances of success.
- Create a Shared Vision among All Team Members: Establish “why” you are making strategic changes so that team members have both a greater understanding of the root cause and a deeper connection to their work. Ensure individual compliance, so people don’t feel like their voices went unheard. Adler emphasizes, “Involve the people who will actually be implementing the change during the planning phase. Ideally, the idea will even come from them. This inclusion greatly increases the buy-in and commitment that the team has to actually getting the project implemented.”
- Choose a Strong Team Leader: The team leader should coach and educate team members along the way and seek out guidance from past implementation plan leaders to improve upon existing implementation processes within the organization. Adler explains that there can be multiple team leaders with slightly different responsibilities: “Each initiative needs a team. The team includes a ’champion,’ someone who is ultimately responsible for getting the thing done. They should also have a ’management sponsor,’ someone that can help the team get through any blocks they might have,” she says.
- Define Actionable Goals: Stay specific, define current issues, and identify root causes. Methods for defining current problems include brainstorming, surveys, and new member information forms. You can also use the note card method: Ask each team member to answer three questions anonymously (What is the single biggest issue facing our team?, What will be the most important issue in five years?, What is the best way for our team to be involved in these issues?), separate the cards into piles with similar answers, and count which answers are the most common within the group. Use the highest ranking similar answers to stimulate discussion of how to proceed.
- Create an Action-Oriented Plan: Regardless of the size or predicted duration of your goals, create a plan focused on incremental action (rather than on continual planning). Small steps add up, so stay positive and focus on the future. That said, Hancock reiterates that your plan must be realistic: “Make sure your plan is reality-based,” she says. “You need to know what problem you really should be solving so that you don’t end up solving proxy problems (problems you think are your problem but really aren’t — an example of this is praying for rain when your real problem is that you need water on your field). You need to know what is really going to impact your problem so that you don’t pray for rain, which doesn’t affect anything. And, finally, you need to know what you really need to do to get the work done. What resources do you need? Do you have the resources you need? Can you get the resources you need? If not, your plan won’t work” she continues.
- Value Communication: The team leader should not only value others’ input, but also make active participation an expectation. Open, honest communication keeps processes transparent and helps generate new ideas.
- Continually Monitor Incremental Success: Perform analysis and hold regular progress meetings to analyze your development. Closely monitoring your progress enables you to make adjustments before crisis hits and allows you to adapt before processes or expectations become solidified. Additionally, treating incremental milestones as successes helps foster a culture where employees feel valued for their contributions. Adler explains, “Building a culture where employees expect that projects will be successfully implemented is important. Celebrate successes and reference previous projects frequently.”
- Involve the Correct People at the Correct Times: This includes defining when and why it is appropriate to involve upper management. As McKenzie says, “Include the critical stakeholders that are part of the project. The beginning of planning should only include the decision makers and not every team member that is part of the project. Outline the critical tasks that are needed first. Once the tasks are outlined, dictate the personnel who will be responsible for the tasks. Once you identify the personnel, then bring in the additional resources to find what other tasks are needed to complete the larger tasks. To draft a proper implementation plan, it is imperative to include the critical stakeholders to outline the initiative.”
- Publicize Your Plan: While you don’t necessarily want every stakeholder’s input at all times during implementation planning, you do want to maintain transparency with other teams and management. Make your plan available to higher-ups to keep your team accountable down the line.
Difficulties in Implementation Planning
While implementation planning is critical to successful execution, there are several hurdles:
- Unless you are disciplined about moving into the execution phase, you can get stuck in planning and never get your project off the ground.
- In any project, you may struggle to gain buy-in from key stakeholders.
- It can also be difficult to break down every goal into an actionable step. If you keep your goals tangible, you can more easily identify targeted actions that will move you toward them.
- No matter how well you plan, all projects have a high propensity for failure. Don’t get discouraged, though — dedicated, strategic implementation planning will raise the likelihood of project success.
Although the above hurdles can be time-consuming and tedious, they are investments that will help you create a culture of trust. Because implementation is an ongoing team effort, you can’t afford to lack buy-in and commitment from any member of your team or direct stakeholders. So, communicate often and honestly, and prioritize teamwork when implementing your strategic plan.
Still, even though inclusion and teamwork are key to a successful strategy, McKenzie reiterates that implementation planning won’t work if too many people are involved. “Implementation planning often gets derailed due to the input from various people that are not involved in the project,” he says. “There needs to be a clear line between the implementation team who is responsible for the execution and final project completion and the customers, internal or external, who are the recipients of the project. The customers can outline their requirements, but the implementation, tasks, and deliverables should be guided by the implementation team,” he concludes.
Adler explains that another common mistake is taking on too much at once. “It takes a lot of work to get something significantly new implemented,” she notes. “For this reason, the fewer initiatives the business takes on simultaneously, the greater the chances of success. Each initiative will take its team members away from their ‘normal’ work to some degree, and the business needs to be able to support this. If there are six things the business wants to implement, it is better to take on one or two at a time than to try to tackle all six at once,” she points out.
Tools for Successful Implementation Planning
While the implementation plan itself is a relatively low-tech document, software tools can help you track and manage your progress. From Gantt charts to advancements in information and communication technology, you’ll find popular implementation planning tools and their benefits below.
A Gantt chart is a graphical bar chart that you can use as a project timeline, and many software programs exist that allow you to create these online charts. As you move from implementation to execution, a Gantt chart can help you track individual task progress, see relationships among tasks, and identify critical or at-risk tasks.
Download Basic Gantt with Dependencies Template
Excel | Smartsheet
You can use a PERT (program evaluation and review technique) chart to forecast project duration by creating a timeline for individual tasks and identifying dependent tasks. PERT requires you to forecast three separate timetables — the shortest possible, the most likely, and the longest possible — which forces you to stay flexible in your planning, so you can adapt your schedule as factors inevitably change over the course of a project.
When you have successfully implemented your plan, you’re ready to move to project execution. Execution planning and monitoring is outside the scope of this article, but below you’ll find more helpful templates to move your project toward successful completion.
Download General Action Plan Template
Excel | Smartsheet
Download Project Timeline Template
Excel | Smartsheet
Download Project Charter Template
Excel | Word | Smartsheet
Advancements in information and communication technology (ICT) have led to the development of cloud-based software that allows for anytime, anywhere access and multiple users. This technological capability is especially helpful for group work, in which multiple team members need to access a certain file simultaneously while also avoiding version control issues. For example, organizations commonly use cloud-based software to create a project management system or performance management system.
Using software to manage your implementation plan can provide the following benefits:
- Drive Accountability: By creating a single record of project progress, you build transparency (both in team members and processes) and reliability.
- Keep Everyone up to Date: All users can access the most current information, which, in turn, cuts out unnecessary communication or erroneous double-work.
- Improve Flexibility: Project management software can help you identify bottlenecks and potential problems early on, so you are able to adapt in anticipation. If you are attempting Agile project management, flexibility is crucial.
- Support Organizational Commitment: Using a software tool often provides the transparency necessary to get executives to support your project. Once they have visibility into processes and progress, they will be more likely to grant the buy-in you need to procure resources and succeed.
When deciding which tool to use, consider the following:
- Buying Tools vs. Developing Software Internally: This will depend on the capabilities and availability of your in-house developers as well as on your budget. Additionally, consider whether or not you have the bandwidth to engage with a vendor and maintain the relationship over time.
- Open Source vs. Free vs. Subscription: Open source software provides a great opportunity for organizations with limited budgets and development resources to build on top of the existing open platforms. There are also many free programs available (not open source). However, be wary that free options may have limited functionality. For organizations with larger budgets and a greater need for powerful functionality, most paid platforms bill on a subscription basis.
- Usability Requirements: Consider your team’s skill level. While you might be drawn to a tool with fancy functionality, it will be pointless (and perhaps even detract from project success) if it is too difficult for your team to use or learn.
Ultimately, software tools are a fantastic way not only to elevate the accuracy of tracking project metrics and progress, but also to save time, build flexibility, and stimulate communication among your team.
Improve Implementation Efforts with Smartsheet
Empower your people to go above and beyond with a flexible platform designed to match the needs of your team — and adapt as those needs change.
The Smartsheet platform makes it easy to plan, capture, manage, and report on work from anywhere, helping your team be more effective and get more done. Report on key metrics and get real-time visibility into work as it happens with roll-up reports, dashboards, and automated workflows built to keep your team connected and informed.
When teams have clarity into the work getting done, there’s no telling how much more they can accomplish in the same amount of time. Try Smartsheet for free, today.
Время на прочтение
15 мин
Количество просмотров 57K
В последнее время мне приходится много работать как с менеджерами проектов так и с заказчиками, и я все больше убеждаюсь, что основой хорошего проекта внедрения и доработки информационной системы служит план проекта, разработанный в MS Project. Его можно показать заказчику, для того что бы наглядно продемонстрировать сроки и скоуп проекта, его можно включить в договор в качестве графика работ, его можно использовать для планирования ресурсов на проекте, с помощью него можно аргументировать те или иные сроки проекта, а так же можно считать внутреннюю и внешнюю стоимость, оценивая ресурсы на специальном представлении.
Для того что бы не объяснять каждому новому ПМу как делать план в Project’e и какие работы и какую структуру туда закладывать, я решил сделать некий драфт плана, который показывал бы типовую структуру работ по проекту внедрения и доработки простой информационной системы, стоимостью приблизительно 5 миллионов рублей и сроком около полугода. Условно, заказчик хочет стартовать проект в мае, а завершить в октябре, при этом старт проекта для нас — начинается в апреле, с подготовки пилота и КП.
Описание проекта
Некая компания, работающая в сфере производства определенных благ, хочет автоматизировать некий участок своего бизнеса.
Для этого они решают обратиться к компании по производству программного обеспечения, с целью внедрить одно из имеющихся решений и параллельно выполнить доработку этого решения под свои нужны.
Риски проекта
Поскольку никакого Rocket Science в проекте нет, его риски составляют около 10%. Заложить их можно по разному — добавить 10% к стоимости ресурсов (но это не учитывает сроки), планировать работы с учетом рисков накидывая 10% длительности к каждой сколько-либо рискованной (именно такой вариант использовал я), или сделать этап Contingency перед завершающим этапом (в моем случае он бы составлял 3 недели или ~1/10 от длительности проекта.
В случае, если план проекта будет показан заказчику, безусловно лучше использовать подход с включением рисков в оценки всех работ — не все поймут появление еще одного этапа (за который заказчик должен заплатить). Но в случае, если вы делаете внутренний проект для своей компании, предпочтительнее включить этап Contingency и использовать данное время для внештатных ситуаций — болезни ключевых сотрудников, внезапных корпоративов и т.д. Внутреннему заказчику будет легче транслировать перенос сроков.
Команда проекта
Руководитель проекта — менеджер, с хорошей технической экспертизой и навыками бизнес- анализа. Хорошо разбирается в функциональности решения, понимает бизнес-задачу заказчика.
Аналитик — проводит встречи по анализу, занимается разработкой проектной документации (протоколы встреч, описание функциональных требований, спецификаций, инструкций и т.д.)
Специалист по внедрению — отвечает за внедрение решения, организацию инфраструктуры для серверов, а так же их связь с внешним миром. Т.е. настраивает ОС, БД, отвечает за трекер поддержки и т.д.
- Ведущий разработчик — он же архитектор. Участвует в проработке архитектуры решения, оценке задач по разработке, обеспечивает наставничество команде разработки и помощь в решении сложных задач.
- Разработчик — основной разработчик проекта,
- Младший разработчик — джуниор на подхвате кода, решает задачи под контролем разработчика, параллельно учится.
- Аккаунт — менеджер по работе с клиентами, отвечает за взаимодействие с клиентом, составление и подписание договоров, контроль удовлетворенности клиента и т.д. В проектный ФОТ напрямую не включается, т.к. его работа не планируется РП.
- Куратор — высший менеджер компании исполнителя, обеспечивающий контроль и поддержку проекта. Может быть так же — руководитель портфеля проектов и т.д. В проектный ФОТ напрямую не включается, т.к. его работа не планируется РП.
- Заказчик — все сотрудники заказчика, привлекаемые к проекту. В плане — не детализируемы, предполагается что заказчик сам решит, кого из своих специалистов привлекать к тем или иным активностям.
Конечно, нам нужно забить команду проекта на представлении «Лист ресурсов» — я просто указал роли, краткое наименование и внутренние ставки (они «средние по больнице» и не привязаны к конкретной компании), а так же указал свой базовый календарь (в общем, соответствующий производственному календарю на 2018 год). Если вы используете сервер проектов, в дальнейшем вы можете указать вместо роли — конкретных исполнителей, но на данном этапе — важны именно роли, для понимания необходимости сотрудников той или иной квалификации. Если вы готовите план проекта для представления заказчикам, есть смысл заменить внутренние ставки на внешние — и то и другое вы наверное уже знаете, а если нет — то это повод обратится к владельцам ресурсов, которые их откроют.
Минимум миниморум:
Конечно, роли могут быть другими — все зависит от компании (и методологии) в которой вы делаете проекты. Одним даром не нужен аналитик и внедренец, у них есть консультанты, другие делят аналитиков на бизнес и системных и добавляют техписателей, третьи используют стажерские программы с подключением сотрудников и т.д. У меня — один из множества вариантов команды, на листе ресурсов можно смело заменить сущности на свои и добавить новые.
Здесь, мы отмечаем заказчиков — зеленым цветом, а специалистов нашей компании, не подлежащих к расчету ФОТа — фиолетовым. Кроме того, что это наглядно, это так же удобно в дальнейшем, например если заказчик попросит сформировать график его привлечения к проекту — вы просто выгрузите план в Excel и отфильтруете по цвету.
Жизненный цикл проекта
В данном кейсе использован очень простой и распространённый жизненный цикл проекта — хорошо знакомый всем «Waterfall» где несколько фаз следуют друг за другом.
Некоторые части проекта все же сделаны итеративно — например разработка разбита на итерации, в конце каждой из которых — реализуется показ разработанного функционала заказчику.
Но тем не менее, такой жизненный цикл не предполагает каких либо серьезных изменений в ходе проекта, поэтому предполагается что скоуп проекта определен на этапе входа в проект, а ограничения по скоупу разработаны и включены в договор. Стоит так же отметить «Этап 0» — на котором происходит оценка скоупа и организация пилотного проекта (для некоторых компаний это нынче редкость) — здесь предполагается что руководитель проекта выступает так же неким руководителем пресейла, в котором он описывает и оценивает функционал, а так же неким руководителем «пилотного» проекта — цель которого, познакомить заказчика с функционалом системы, показать ему интерфейс и преимущества на берегу, что бы заинтересовать его. Пилотный проект назвать проектом можно лишь условно — естественно, это просто стандартная заготовка системы минимально дорабатываемая под нужды конкретного заказчика. Например, виртуальная машина со стабильной версией системы, в которой может быть быстро реализована пара простых, но реальных процессов заказчика, и, например, быстро настроена связь с одной из используемых им систем (на основе уже существующего драйвера, или коннектера, требующего лишь простой настройки).
Так же для экономии места на экране я убрал отображение поля «Режим задачи» — на всех задачах он автоматический, ручного нигде нет.
Общий обзор этапов, их сроков и стоимости:
Итак, у нас есть 8 этапов (включая этап 0) и проект, который начинается 2 апреля, завершается 5 октября. Заказчику — можно вовсе не показывать этап 0, и конечно, не стоит его учитывать если вы не считаете ФОТ пресейлов и пилотов (но это для первый звоночек того, что вам есть над чем поработать, так как такой ФОТ считать нужно обязательно).
Здесь и далее — все вехи раскрашены синим цветом, для того что бы быстро идентифицировать их. Вехи указывать обязательно надо, т.к. вы сможете вставить их в договор, привязывать к ним другие задачи или оплаты этапов, да и вообще следить по ним, как движется проект.
Этап 0 — подготовка проекта
В нашем проект все начнется с пилота — в один прекрасный день аккаунт приходит к ПМу с радостной новостью о том, что у него есть заявка на пилот.
Для организации пилота, от заказчика потребуется пара описаний его процессов, а так же пара пожеланий, которые он хочет видеть в системе — например, он хочет загрузить какой либо список из своей уже существующей стандартной БД.
Здесь, мы несколько дней общаемся с заказчиком по телефону, запрашиваем описание процессов или экранных форм, дальше быстро пилим пилотный проект для демонстрации и отправки заказчику. Предполагается, что пилотный проект не требует сложного развертывания, например это либо виртуалка, которую заказчик может оперативно развернуть в своей инфраструктуре, либо вообще облачный сервис.
При средних ставках внедренца и ПМа такой пилот будет стоить нам 59 400 рублей + еще 10800 рублей на его сопровождение, ведь у Заказчика появятся вопросы про его развертывание и использование. Ну как, вы все еще не хотите считать затраты на нулевом этапе?
Далее, если заказчику понравился пилот, мы приступаем к анализу скоупа проекта и его оценке. Предполагается, что проект типовой и все методы оценки уже разработаны и опробованы в вашей компании — если это не так, то вас ждет увлекательный аттракцион по сравнению стоимости работы написания ТЗ со стоимостью разработки функционала, покрывающего то, или иное требование (но это тема отдельной статьи).
Предположим, процесс описания скоупа и оценки у вас поставлен на поток, и после оценки куратор проекта одобряет ее (и накидывает % на торг и внепроектные риски) после чего КП отправляется на согласование заказчику. Здесь указанных 7 рабочих дней может быть явно мало, поэтому эта работа указана отдельно, и именно от нее зависит веха «КП Утверждено».
Разделять задачи по организации пилота и оценке скоупа проекта — надо, т.к. вы должны хорошо понимать их стоимость, и пытаться оптимизировать затраты на подготовку пилотов и оценку (например, создать типовые шаблоны для оценки и типовые виртуалки для внедрения).
Этап 1 — сбор требований
Итак, вы успешно подписали контракт (или получили одобрение от спонсора внутреннего проекта) и теперь самое время стартовать, начав со сбора требований к системе. Но перед этим, надо надо устроить kick-off meeting, или как это называется на русском, стартовую встречу.
В некоторых проектах есть смысл показать разработанный Project Charter, в некоторых проектах вместе с договором подписывается официальный устав, но независимо от этого кикофф нужен — для того, что бы ясно объяснить цели и сроки проекта команде (или командам) и познакомить всех друг с другом, договорится о взаимодействии. В общем, проведение Kick-off — это тоже тема отдельной статьи.
Т.к. проект небольшой, мы предполагаем, что 12 часов за глаза хватит нам, что бы подготовить небольшую презентацию, в которой мы вкратце обозначим цели и задачи проекта, участников и их роли, наглядно покажем сроки проекта (например, красивую диаграмму Ганта) и представим следующие шаги (например график встреч с заказчиком).
А вот кстати, и график встреч — для нашего простого проекта мы предусмотрели 6 встреч, на которых участвуют разные специалисты и которые стоят для нас по разному. Предполагается, что график мы заранее согласовали с заказчиками (или спонсорами), что бы бизнес-пользователи и вообще все заинтересованные лица, не ушли в отпуска или не были заняты на других активностях. Конечно, если вы работаете над внешним проектом, есть смысл включить план проекта в договор — в этом случае никто не сможет обвинить вас в срыве сроков, если заказчик по каким то причинам не сможет присутствовать на встречах.
Рассмотрим несколько встреч на примере:
На одних встречах — нам нужен только менеджер проекта и аналитик, на других — нужен еще ведущий разработчик, а так же может понадобится и внедренец. Это зависит от конкретного проекта, но в общем случае — планируйте встречи так, что бы все технические детали всплывали в конце, после требования бизнеса — это уменьшит вероятность того, что договоренности на встречах придется согласовывать.
Логическим окончанием встречи у нас является ее протокол, высланный на ревью заказчику. Здесь важно учесть следующее — у меня встреча и составление протокола — запланированы на 1 день, т.е. утром проходит встреча, далее обед и пишется протокол, который отправляется на согласование заказчику. Заказчик же, в то время как команда проекта пишет протокол, согласовывает протокол предыдущей встречи.
Естественно, это идеальный вариант, который работает только при наличии 2 очень сильных и мотивированных проектных команд.
В реальной жизни — отсидеть на встрече 4 часа и за 4 часа составить приличный протокол с описанием требований и договоренностей (или отревьювить его) — и так 6 дней подряд — довольно тяжело. Не говоря о том, что встреча может быть и более 4 часов (кстати, в этом случае эффективность встречи резко падает и протокол может быть и не согласован). Если сроки (и заказчик) позволяют — заложите 1 встречу в 2 дня, и возьмите запас недельку — для проведения дополнительных встреч и ревью протоколов. Если вы на 100% не уверены в заказчике и команде — никогда не ставьте на неделе более 3 встреч. Ну и конечно, все зависит от региона присутствия — если вы делаете проект в своем городе, или хотя бы в своей области — тут торопится смысла нет. Если же ваш заказчик из Нового Уренгоя, а вы — из Самары — увы, придется выложится на встречах по полной — мариновать команду без работы в другом городе нет никакого смысла. Так же, обязательно пропишите участие заказчика во встречах отдельной строкой — и вставьте это в договор.
Этап 2 — Архитектура и дизайн
Этап, который на плане проекта выглядит довольно просто — на самом деле один из самых трудоемких и дорогих. Кроме этого, ошибки в проектировании технического задания (технического дизайна, концепции, да вообще любого документа, который де-юро служит основанием для разработки и поводом для обращения к подрядчику по гарантии) стоят как правило очень дорого. Изменения на этом этапе еще приветствуются (если они не выходят за ограничения, указанные в договоре), но т.к. обсуждение уже закончено — новые требования добавлять уже не рекомендуется.
Для внутренних проектов — выше риск того, что появятся новые требования (фантазия спонсора и бизнес-пользователей тут как правило не ограничена договором), но в то же время согласование не такое жесткое и формальное.
Есть ли смысл детализировать эти 5 дней в задачи и отражать их в плане проекта? На мой взгляд нет, логичнее сделать это в Jira/Redmine, а заказчику/спонсору показать такой план.
У меня предусмотрено 2 итерации согласования — это совершенно разумно, но требует от заказчика определенной ответственности — на берегу стоит объяснить, что все замечания к ТЗ Заказчик выставляет в одной итерации, а во второй — только проверяет их исправление, а новые замечания — не ставятся. Если заказчик настаивает на третей итерации замечаний — что ж, хозяин барин, вставляем и третью (и четвертую, и пятую…) не забыв прописать затраты и объяснить заказчику насколько вырастет стоимость проекта. Презентовать ТЗ первый раз разумно вдвоем с аналитиком, а вот вычитывать его необходимо всей команде — на сколько либо больших проектах это весьма емкий документ, который является условием для завершения фазы проекта (а следовательно подписания актов и оплаты), и случайные ошибки в нем не допустимы. Если у вас в компании есть свободные ресурсы, например аналитики, логично подключить их к чтению ТЗ в качестве свежего взгляда — ТЗ от этого хуже не станет, а проект не подорожает на сколько бы существенно.
Этап 3 — Разработка
Итак, техническое задание подписано, и казалось бы можно приступать к разработке.
Первое, о чем хочется сказать — это предупредить о недопустимости начала разработки, без утвержденного ТЗ. Это ведет просто к тому, что одну и ту же работу приходится делать 2 раза. Конечно, если вы работает по Agile, и у вас четких требований нет, а есть заказчик платит по схеме Time&Materials, тогда смело игнорируйте это требование. Если же скоуп проекта у вас утвержден, оплата FixPrice и вы не закладывали бюджет и сроки на переделку задач, то не позволяйте разработчикам сделать ни единого коммита, без подписанного ТЗ.
Второе — конечно подразумевается, что инфраструктура для разработки развернута, а процессы отлажены. Нерадивые спонсоры и кураторы проектов, стремятся включить в бюджет проектов такие расходы — переход на использование CI, развертывание Jira/Redmine, переход на новую версию ПО и библиотек, БД и т.д. и т.п. Задача ПМа здесь — защитить свой проект (и его бюджет) от такого, аргументируя что такие вещи должны быть вынесены в отдельные проекты с отдельными бюджетами.
Если вы работает по Waterfall — делать разработку стоит итерационно — т.е. разбить весь скоуп на части и показывать заказчику/спонсору по мере наработок. Пускай в софте еще будут баги, пускай нет данных, пусть формы не доделаны — лучше потратить бюджет и время на написание сценариев показа и дополнительные тесты, чем пропасть на месяц с глаз заказчика и появится с готовым продуктом. Фидбек заказчика на этапе завершения итерации разработки так же полезен, но это не значит что его надо бездумно пихать в скоуп — оцените его замечания. Если он предлагает что то несущественное — например, сменить цвет или размер поля на форме — покажите что вы лояльны и приветливо согласитесь. Если заказчик предлагает откровенно сложный функционал — откажитесь, аргументировав отсутствием в скоупе, а если заказчик настаивает — запускайте свою машину changemanagment’а (конечно, она у вас есть). Бывает, что заказчик предлагает казалось бы что то не существенное, например поменять формат телефонного номера, но это может сказаться на всей системе. В этом случае, посоветуйтесь с ведущим разработчиком/архитектором, возьмите его оценку под этой фичей, если она небольшая — можно пойти навстречу заказчику для повышения лояльности (но стоит помнить о риске ошибки оценки).
Но все это еще впереди, а пока, вам нужно будет декомпозировать задачи из ТЗ в задачи в трекере задач. Здесь подробного универсального рецепта нет, но в общем случае — создать задачи по каждому функциональному требованию, и в его рамках создайте подзадачи. Далее, используя методы оценок (например покер планирования), вы с проектной задачей оцените трудоемкость задач. Не забудьте расставить приоритеты задач, в соответствии с итерациями (можете прикрутить к описанию задач номера спринтов, и планировать исходя из производительности команды). В плане проекта всегда разумно указать, что является результатом той или иной итерации (например разработаны экранные формы, интеграция, аналитика или что то еще) — что бы заказчик знал, что он получает на показах и мог отслеживать, идете ли вы по плану, или задерживаетесь. Постарайтесь разбить итерации исходя из вашего опыта, но в любом случае — не пропадайте надолго, и ведите протоколы показа, куда заносите замечания от заказчиков, с вашими решениями по ним — это прикроет вас, в случае конфликта относительно скоупа проекта — иначе говоря, поможет избежать ситуации на сдаче-приемке — «Не подпишем, мы ведь говорили, что окошко надо было делать синим…».
Этап 4 — Тестирование
Итак, все задачи в Jira закрыты, все протоколы согласованы и теперь мы вступаем в этап тестирования продукта, разрабатываемого в рамках проекта.
Перед тем как тестировать — вам конечно понадобится тест-план и тест-кейсы, с оценкой их прохождения.
Обратите внимание на задачу 110 (исправление дефектов) — она параллельна 109 (поиску дефектов) с задержкой в день. Т.е. предполагается, что тестировщик, проходя по тест-кейсам, описывает дефекты в системе задач, а разработчики правят их не отходя от кассы. Такой подход разумен и используется, но есть и другое решение — приступать к починке только когда тестирование будет завершено. Какой из этих подходов подойдет именно вам — знает ваш руководитель разработки.
Не забывайте, что заказчик тоже захочет протестировать систему — на этот случай вы предоставите ему документ который называется «ПМИ» — или программа и методика испытаний. Сделать его логично на основе разработанных тест-кейсов, убрав всю внутреннюю кухню и оставив только нужные заказчику вещи (в т.ч. нефункциональное тестирование).
ПМИ должен быть прочитан и утвержден заказчиком и именно по результатам прохождения ПМИ, заказчик будет принимать итоговое решение о переводе системы в промышленную эксплуатацию.
У меня в проекте — согласование ПМИ не включено, т.к. на моей практике, заказчики редко вчитываются в ПМИ и тест-кейсы, ибо слабо понимают о каком конкретно функционале идет речь и чем в одном случае чек-бокс отличается от радиобаттона в другом случае (это шутка, такое вообще в ПМИ писать не надо). Поэтому при разработке документа, особое внимание следует уделить списку кейсов, о прохождении которых пойдет речь, и конечно, проследить что бы они были нормально проработаны внутри.
Пройти ПМИ должны не только тестировщики, но и ПМ и аналитики, и желательно внедрение — сдавать систему придется всем вместе, и иметь представление о том, как работает функционал — очень полезно, и конечно. повышается шанс найти неочевидные дефекты.
Этап 5 — Внедрение
Ура! Мы добрались! Система на тестовых серверах работает как часы, команда QA отсыпается и уходит в отгулы, и пришел звездный час команды внедрения. Начинается он с развертывания окружения — и тут же у меня в плане заложен некий запас по времени, т.к. я подразумеваю что окружение развёртывали уже минимум 100 раз и в худшем случае на вашей корпоративной вике есть подробная инструкция по развертыванию, а в лучшем — внедренец сам ее писал. Главное, помните — после развертывания полезно протестировать все, что вы можете протестировать по заранее разработанному смоук-тесту, конечно же он остался у вас с фазы тестирования.
Теперь — о главном, ведь если дьявол и кроется где то, то это именно в интеграции и миграции данных. Сколько красивых диаграмм Ганта было погублено тем, что интеграция не была оттестирована тщательно и тем, что данные заказчика находились в ужасном состоянии, ненормализованные, выходящие за все грани разумного (и пределы полей), отличные от того, что написано в ТЗ.
Здесь главное — не дать заказчику сыграть на том, что интеграция (или миграция) может не заработать и переложить ответственность на вас — предупредите его заранее о том, что если эти работы будут задержаны по его вине, ответственность за увеличение сроков (и бюджета) проекта ляжет на его плечи. Не стесняйтесь писать письма и созывать ProjectBoard (или что там у вас) ибо интеграция и миграция пользовательских данных — это самая частая проблема срыва сроков на подобных проектах.
Обучение (тут вас ждет приятный сюрприз) — почти не таит в себе подводных камней. Согласуйте план обучения с заказчиком, и пишите протоколы на всех присутствующих под роспись. Ну и конечно, если вы не уверены в работе своего аналитика — запланируйте еще день репетиции обучения (либо включив это в три дня по написанию инструкций, либо используя внутренний бюджет на риски проекта).
На прохождение ПМИ — планируйте от 25% времени ПМа и выше, в зависимости от вашего опыта и годности аналитика, который участвует в проекте — в идеале испытания должны проходить как по маслу, ну и во всяком случае в этом должен быть уверен заказчик по крайней мере до начала испытаний.
Если же испытания идут через пень колоду — виноват в этом ПМ, ПМ и еще раз ПМ — значит предыдущие фазы были или плохо запланированы, или плохо реализованы — ищите причину и решайте проблемы, но уже не за счет заказчика, а за счет рисков, который вы заложили на старте проекта.
Этап 6 — Поддержка
Или, как ее называют — сопровождение ОПЭ (т.к. с гарантийной или технической поддержкой это общего почти не имеет). Итак, вся пицца съедена, бессонные ночи закончены, и ваш проект перешел в промышленную эксплуатацию. Это значит что у заказчика нет (или он просто не сумел найти) критичных замечаний к системе, разработанной в ходе вашего проекта, и дает пользователям команду работать в ней, как в основной системе (или как в клоне боевой системы, такое тоже бывает).
Теперь, ваша задача продержаться определенный период (от 5 дней до 4 месяцев) и убедится что система работает правильно. Выбор сроков зависит от назначения системы — иногда хватает и недели работы в новой системе, иногда нужно проработать в ней месяц или два, а то еще и квартал закрыть. Планируйте на это время людей, что бы они могли оперативно разобраться с возникшими у заказчика вопросами, но учтите, что вопросов может быть (должно быть!) немного — поэтому логично запланировать так же внутренние проектные активности — архивирование документации, приведение в порядок вики и трекера задач, подготовку ретро и т.д.
Не забывайте, что все проблемы, возникшие в ходе ОПЭ, надо фиксировать в специальном журнале (а в идеале — в трекере задач) и ежедневно отслеживать их статус совместно с заказчиком.
По окончании этапа можете так же запланировать одну встречу команды с заказчиком, где вы торжественно объявите о закрытии проекта и продолжении сотрудничества и подведете итоги. Если только ваш заказчик не в Новом Уренгое.
В общем то это все, конечно, хотелось бы выложить куда то план проекта в формате mpp — для того, что бы уважаемые хабровчане могли не забивать все это руками, а посмотреть на примере каким образом связаны задачи.
Предложения по этому — я выслушаю в комментариях, и обязательно опубликую mpp в месте, где его можно будет легко и безопасно забрать.
Данная статья довольно необычна для нашего ресурса. В ней вы не найдете ни слова о технике. Наоборот, мы поговорим об организационных вопросах с которыми приходится сталкиваться администратору. Ведь одних технических знаний зачастую недостаточно, чтобы успешно реализовать в жизнь все планы и задумки.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Внедрение – как много в этом слове… Для системного администратора это хороший повод показать себя, либо нажить кучу проблем на ровном месте. И что самое обидное, это никак не будет зависеть от того насколько грамотно и качественно вы выполнили техническую часть работы, зато очень много будет зависеть от того, как вы ее организовали.
Независимо от того, сами вы будете делать внедрение или приглашать сторонних специалистов, а также от его сложности и масштабности (неважно, ставите вы новый файловый сервер или меняете IT-инфраструктуру предприятия), первое о чем должен позаботиться администратор – это детальное планирование будущего внедрения. В любом случае весь последующий “головняк” достанется вам, и чтобы вместо благодарности и премии не получить полный набор неприятностей к теме нашей сегодняшней беседы следует подойти со всей серьезностью.
Итак, с чего начинается внедрение? С новых серверов и нового ПО? Нет, до этого еще надо дожить. Любое внедрение начинается с вещей гораздо менее интересных. Пройдем по основным этапам.
Постановка задачи.
Как обычно происходит, вызывает вас утром шеф и говорит: “Знаешь, я подумал – нам надо сделать свою электронную почту” или “Тут отдел продаж жалуется, тормозит у них, надо что-то сделать”. Очень редко, когда руководство ставит конкретную задачу, в большинстве случаев перед администратором ставится проблема либо пожелание – выбор решения, его реализация и ответственность за это полностью ложится на его плечи.
“Ну что, сделаешь?” – спрашивает шеф, не спешите бить себя пяткой в грудь и уверять что для вас это раз плюнуть, сейчас проверяют не ваши знания и квалификацию, а вашу способность предложить для предприятия оптимальный вариант. На этом этапе вы должны выяснить, какие именно функции нужно реализовать и в каком объеме, а также какой экономический эффект ожидается от данного внедрения и какой его предполагаемый бюджет.
Не бойтесь и не стесняйтесь говорить о возможных трудностях и проблемах, либо о дополнительных затратах. Этим вы покажете себя как грамотного специалиста, думающего в первую очередь о потребностях предприятия. Если же руководство требует “как-нибудь, чтоб работало” реализовать его запросы на текущем и явно не подходящем оборудовании, то стоит задуматься о смене работы.
Если для внедрения требуется новое оборудование, так и скажите об этом. На недоуменный вопрос: “Мы же полгода назад купили новый сервер, ты сам выбирал”, поясните, что тогда не стояло таких задач, а покупать сервер “на вырост” – это деньги на ветер, т.к. оплаченная вычислительная мощность не будет использоваться.
В ряде случаев будет также неплохо, если вы сами придете к руководству с предложением, при этом надо четко объяснить, что именно станет лучше после внедрения. При этом забудьте на время технические термины, объяснение что серверу нужно добавить оперативки или купить новый процессор будет воспринято руководством как выпрашивание денег на непонятные нужды. Зато если вы объясните, что количество пользователей сервера увеличилось и уже сейчас некоторые пользователи жалуются на недостаточную скорость работы, а при планируемом расширении есть риск того, что производительность неприемлемо снизится, то руководство будет только за принятие мер для повышения быстродействия. И вы вместо человека живущего на другой планете и говорящего какие-то непонятные вещи, заслужите репутацию толкового специалиста, думающего о нуждах предприятия.
В любом случае к окончанию данного этапа у вас в руках должно быть письменное изложение всех требований к новой системе, которое должно отвечать на вопросы: какие именно функции должна иметь новая система, кто должен иметь доступ к этим функциям и в каком объеме и предполагаемый эффект от данного внедрения. И только после этого, но не раньше, можно переходить к следующему этапу.
Формализация требований.
Имея на руках список требований можно переходить к их формализации. Ничего сложного и страшного в этом слове нет, просто вы должны “перевести” поставленную задачу с обычного языка на технический. Фактически вам надо составить техническое описание будущей системы. Какие функции и компоненты требуются, какая должна быть нагрузочная способность, требования к доступности и отказоустойчивости.
На этом этапе постарайтесь абстрагироваться от конкретных программных решений, сосредоточитесь на общем описании системы, гораздо более правильно подбирать ПО под задачу, чем подгонять задачу под имеющееся ПО.
Еще один очень важный момент, про который многие забывают, это список показателей и критериев, по которым следует проводить оценку эффективности системы. Очень хорошо если это будут не “попугаи” бенчмарка, а некий набор показателей, применимый к повседневной деятельности предприятия. Если возможно, выполните нагрузочное тестирование. Если стоит выбор между синтетическими тестами и тестированием на реальных приложениях – выберите последнее. Составьте набор тестов с использованием реальных приложений и учитывающий круг повседневных задач. Также обязательно проведите тестирование существующей системы, чтобы потом была возможность сравнить. Помните, что руководству гораздо интереснее насколько быстрее формируются отчеты и т.п., чем сколько “попугаев” получила система в каком либо бенчмарке.
Пренебрежение этим требованием может сыграть с администратором злую шутку. Внедрение может быть выполнено безукоризненно технически, но если эффект от него не виден невооруженным глазом и вы не сможете доходчиво объяснить, какие преимущества получило предприятие, руководство может счесть внедрение неудачным, а средства потраченными впустую. Ситуация, что говорить, весьма неприятная, учитывая что админ честно выполнил свою работу, поэтому оценке эффективности внедрения следует уделить повышенное внимание. Не забудьте согласовать выбранные вами показатели с руководством, возможно у них несколько другие параметры оценки.
Выработка решения
На этом этапе вы должны предложить решение поставленной задачи с конкретным указанием всех необходимых для этого ресурсов и работ. А также определиться, кто какие задачи будет выполнять и установить сроки.
Еще раз повторимся, не занижайте требования, даже к недовольству руководства. Если внедрение объективно требует двух недель, а руководство настаивает на неделе, подготовьте перечень необходимых работ и аргументируйте сроки, будет гораздо лучше, если вы закончите работу раньше, чем сорвете сроки. И не надо винить во всех своих бедах “самодуров” из руководства. Пообещав конкретные сроки, вы даете руководству отправную точку для дальнейших действий, например на окончание внедрения может быть запланирована рекламная кампания, с расчетом на новые возможности предприятия, в этом случае срыв сроков череват как прямыми убытками, так и уроном для деловой репутации фирмы.
Также, если внедрение требует новый сервер для реализуемого решения, не пытайтесь пойти на компромисс с руководством, реализовав это на имеющихся мощностях. Это вам будет понятно, что неудовлетворительная работа связана с недостаточной вычислительной мощностью. Для остальных это будет неработоспособностью сервиса и показателем того, что вы не справились с поставленной задачей.
Будьте последовательны и аргументированно отстаивайте свою позицию, за это еще никого не уволили, а вот за проваленный проект можно запросто пойти на улицу. Также определитесь, кто будет реализовывать проект, вы сами или сторонние специалисты. Помните, если вы знакомы с предметом внедрения только теоретически, то лучше пригласить сторонних специалистов, либо убедить руководство в необходимости пройти обучение. При отсутствии реального опыта работы с продуктом обязательно проведите тестирование выбранного решения, хорошим подспорьем тут будет технология виртуальных машин. Если возможно, проведите пилотное внедрение на базе какого нибудь отдела.
В любом случае, перед внедрением, вы должны быть знакомы с внедряемым продуктом практически и иметь базовые навыки работы с ним, знать типовые проблемы и способы их решения. В противном случае лучше пригласить специалистов со стороны. В этом нет ничего зазорного, любой сложный программный продукт имеет свои особенности, недокументированные варианты поведения, типовые неисправности и т.п., которые для специалиста-практика не представляют затруднений, зато новичка способны ввергнуть в длительный ступор.
Мы крайне не советуем браться за внедрение без практического опыта работы с внедряемым программным продуктом, даже имея под рукой многократно проверенный мануал. В случае какой либо нештатной ситуации что вы будете делать? Спрашивать совета на форумах? А время идет, сроки поджимают.
Внедрение
С одной стороны здесь все просто, администратор находится в своей родной стихии, с другой стороны здесь тоже немало подводных камней. Перед тем как браться за внедрение, составьте план действий на каждый день и обязательно документируйте его фактическое выполнение. Если что-то вам помешало выполнить запланированные задачи – укажите причину. Еще перед внедрением решите с руководством что важнее, внедрение или текущие заявки пользователей, а также расставьте приоритеты, например заявки отдела продаж имеют приоритет над внедрением, а отдел закупок может и подождать.
Подобный подход позволяет в любой момент времени показать руководству как идет внедрение, а также вырабатывает самодисциплину и ответственный подход к поставленным задачам. Работы без плана обычно сводятся к тому, что 80% времени занимаются ерундой, а в оставшиеся 20% аврально внедряют, буквально бегая по потолку. Любая задержка, такая как брак оборудования или затягивание сроков третьей стороной, может оказаться для проекта фатальной. Поэтому составьте план и заставьте сами себя его придерживаться, вы увидите, успех не заставит себя долго ждать.
Сдача проекта
Ну вот, внедрение закончено, все работает как часы, тестирование показывает увеличение производительности и кажется, что завтра на вас посыпятся благодарности руководства, премии и прочие приятные бонусы. Но рано расслабляться, проект еще нужно сдать.
Особое внимание следует уделить конечным пользователям. Именно они будут решать судьбу проекта, не один раз технически безупречные проекты проваливались из-за пренебрежения пользователями. Постарайтесь коротко и на понятном им языке сформулировать основные преимущества именно с пользовательской точки зрения, например: “раньше это действие делалось так, а теперь вот так, что гораздо быстрее и удобнее”. А также подготовьте короткие, но емкие инструкции по работе системой.
Помните, что пользователю все равно, как работает система, ему нужно чтобы она помогала ему выполнять определенные производственные функции. Если ему приходится вместо выполнения основных обязанностей тратить время на освоение системы – он будет против, однако если он будет видеть грядущие выгоды – он будет за.
Следует отдавать себе отчет, что IT-отдел это обслуживающий персонал и денег для фирмы он не зарабатывает, в отличие от того-же отдела продаж. В случае конфликта с пользователями руководство станет на сторону пользователей, основная цель фирмы – получение прибыли, а не внедрение IT-технологий.
Мало сделать технически безупречную систему, важно чтобы она была дружественной пользователю. Поэтому если стоит выбор между технически правильным решением и решением удобным пользователю, следует отдать предпочтение второму. Пусть это не эффективно с технической точки зрения, но это удобно пользователю. В конце концов, деньги зарабатывают не сервера, а работающие с ними пользователи.
Подготовьте инструкции для пользователей, расскажите им о достоинствах новой системы, проведите инструктаж и вы получите положительные отзывы, что позволит вам успешно сдать проект.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Меняйтесь раньше, чем вас заставят это сделать!
кому: собственникам, топ-менеджерам
В предыдущих сериях…
Наступили суровые экономические реалии. Собственники всерьёз взялись за повышение эффективности работы компаний и персонала. Всё правильно. Но есть одно важное дополнение. Это необходимо делать системно, ибо в противном случае все усилия будут бесполезны и затратны. На помощь приходит регулярный менеджмент. Внедрять его непросто, но результаты превосходят все ожидания.
При внедрении регулярного менеджмента ваш корабль-компания ожидаемо попадёт в шторм. Шторм помогут уверенно пройти штурманы-консультанты. Если же ничего не предпринимать, то корабль может запросто затонуть в штиль из-за своей ветхости.
В предыдущей статье “Как внедрить регулярный менеджмент в своей компании (часть 2). Пять сценариев внедрения. Роли в проекте. Подбор исполнителей” мной были подробно разобраны варианты сценариев внедрения, определено, по каким критериям необходимо распределять роли в проекте и как подбирать руководителя проектов и с команду по внедрению.
На этом длительное описание Этапа №1: “Договориться со всеми собственниками / партнёрами, распределить роли в проекте” завершено. Пристёгивайте ремни, впереди ускорение.
Оглавление статьи
- Этап №2. Собрать подробные данные о текущем положении дел в компании, отделить “факты” от “мнения о фактах”
- Требуемая информация о текущем положении дел в компании
- Технология отделения “мнения” от “фактов”, или “Розовые очки”, которые вам напяливают подчинённые
- Этап №3. Подготовить план и устав проекта внедрения регулярного менеджмента
- 3.1. Устав и цели проекта внедрения регулярного менеджмента
- 3.2. Типовой план проекта внедрения регулярного менеджмента, или Долгожданная пошаговая инструкция
- 3.3. Ресурсы проекта: потребуются время, деньги и умение “держать цель”
- 3.4. Риски проекта (“пропустить нельзя просчитать” — где бы вы поставили запятую?)
- Этап №4. Выполнить работы по внедрению регулярного менеджмента, взаимодействие в проекте, роль консультантов
- Список функций консультантов в проекте внедрения регулярного менеджмента
- Отчётность и формализация, как технология сохранения информации
- За рамками Этапа №4, или Ответы на часто задаваемые вопросы
- Этап №5. Завершить проект внедрения регулярного менеджмента. Перевести проект в программу: закрепить и поддерживать результаты, развивать силами сотрудников
- На развилке дорог, или Вместо заключения
- Ключевые принципы работы консультантов “Открытой Студии”
Этап №2. Собрать подробные данные о текущем положении дел в компании, отделить “факты” от “мнения о фактах”
Для того чтобы составить подробный план проекта внедрения регулярного менеджмента, необходимо собрать данные о текущем положении дел в компании. В сборе данных активно участвует руководитель проекта и, при необходимости, консультанты.
Вся собранная информация по каждому пункту должна быть формализована в письменном виде. За это отвечает руководитель проекта, а консультанты ему подскажут, как этот процесс организовать.
Этап кажется быстро реализуемым, но только на первый взгляд. На самом деле работу необходимо провести масштабную.
Требуемая информация о текущем положении дел в компании
- Организационная структура (формальные и фактические роли, формальные и неформальные лидеры), особенности существующей системы управления и мотивации; правила, традиции, обычаи в коллективе (важно учесть, что всё это может отличаться на уровне отделов). Собранная информация формализуется в письменном виде.
- Ключевые бизнес-процессы компании, краткое их описание; в каком виде существуют регламенты, база знаний. Какие из них соблюдаются сотрудниками и насколько, а какие игнорируются
- Обязанности сотрудников, краткая профессиональная характеристика каждого сотрудника (прежде всего речь идёт о подразделениях, с которых начнётся внедрение регулярного менеджмента). Руководителей и вовсе “разбирают по атомам”.
- Существующие требования к руководителям; системы контроля, отчётности и планирования.
- Типовые конфликтные ситуации. Типовые ситуации, которые требуют вмешательства топ-менеджмента, руководителей. Ситуации, которые возникали ранее в компании и создавали риски репутации и прибыли компании.
- Информационные системы, которые на данный момент используются или планируются к внедрению: какие задачи решают сейчас; соответствуют ли требованиям к системам в рамках регулярного менеджмента (среди требований: тотальная прозрачность всех поручений сверху вниз, фиксация всех знаний, уровни доступа, планирование и отчётность); есть ли у них возможность донастройки/доработки. Формализация полученной информации.
Технология отделения “мнения” от “фактов”, или “Розовые очки”, которые вам напяливают подчинённые
Обойти эту тему стороной означало бы заложить мину замедленного действия с помощью “недостоверной информации”, полученной… от собственника! Проблема заключается в следующем: как правило подчинённые всех уровней превосходно владеют навыками создания (более того, целенаправленно работают в этом направлении) “радужной” картины миры у своего босса. И в этом есть для них определённая логика.
Вслушиваясь в торжественные реплики сотрудников, можно представить, что ваша компания развивается семимильными шагами и вот-вот на вас лично посыплется дождь “из золотых монет” в форме прибыли и других достижений. вы уже было засучили рукава и подготовили пустые ящики для складирования денег, но… В очередной раз дождя не происходит. Это событие подаётся как невидимая рука рынка и/или злонамеренные действия коварных конкурентов или… дальше список можно продолжать бесконечно.
Отсюда у собственника и топ-менеджеров уровня директора создаётся искажённая картина происходящего в организации. Бывают случаи, когда истинная ситуация настолько ужасна, что хочется просто “сбежать”: куда не копнёшь, везде с гнильцой. Какое там развитие компании! Куда там!
комментарий: Сунь Цзы говорил: “Приближайся к оленю и не промахнёшься”. Чтобы “не промахнуться” с планом проекта по внедрению регулярного менеджмента необходимо отделить “факты” от “мнения”.
Но что же делать? Как узнать правду, которую старательно скрывают подчинённые? Как всё-таки консультантам и самому собственнику отделить “факты” от “мнения”, чтобы подготовить реалистичный план проекта по внедрению регулярного менеджмента? Технология проста: вызывать топ-менеджеров по одному и задавать им вопросы. На каждый ответ задавать новые уточняющие вопросы, просить продемонстрировать результаты работы, всё увиденное и услышанное записывать для последующего анализа.
Например, на вопрос “Как оценивается эффективность ваших подчинённых?” руководитель отвечает: “Мои подчинённые учитывают время по всем задачам”. Отсюда следует следующая последовательность вопросов и просьб: “Как они учитывают время?” “В какой программе?” “Покажите, пожалуйста, их отчёт по задачам за прошлый день/ неделю/ месяц?” “Как посмотреть дату, когда было затрачено время на выполнение этой задачи?” “Как Вы оцениваете и проверяете достоверность указанного времени?” “Как разбираете выявленные недостатки? Где фиксируете об этом информацию?” и т.д.
В рамках регулярного менеджмента “факты” и “мнение о фактах” в первом приближении совпадают
В итоге консультанты, “приближаясь к оленю” (см. текст под картинкой с лисой и вороной) и опираясь на полученные факты, смогут разработать значительно более реалистичный план проекта, нежели если его делать со слов собственника. Чем реалистичнее план, тем большая вероятность его успешного выполнения. Отсюда, тратить время и деньги на отделение “фактов” от “мнения” безусловно имеет смысл.
Ремарка: в рамках регулярного менеджмента “факты” и “мнение о фактах” в первом приближении совпадают, ибо за очковтирательство всегда следует неотвратимое наказание (вплоть до высшей меры — увольнения). Представьте на минуту насколько легче управлять такой компанией.
Этап №3. Подготовить план и устав проекта внедрения регулярного менеджмента
Чувствую, у вас уже “чешутся руки” применить собранные данные. Внедрение регулярного менеджмента — это не только внедрение инновации (для нас важно было рассмотреть задачу с этой точки зрения для правильного распределения ролей), но и типичная задача проектного типа. Поэтому в дальнейшем мы будем её рассматривать в рамках системы координат управления проектами.
Не торопитесь стартовать, сначала предлагаю подготовить план и учесть риски.
Поясню своё понимание определения проекта. Итак, проект — это последовательность взаимосвязанных задач с общими целями и конечным результатом, ограниченная сроками и ресурсами.
3.1. Устав и цели проекта внедрения регулярного менеджмента
Устав проекта — документ, в котором хранятся все ключевые параметры для данного проекта. Среди них: цели проекта, план проекта, этапы, ресурсы, риски, критерии успеха, установленные даты контрольных точек и периодичность отчётности.
Цели проекта были определены и зафиксированы на предыдущих этапах (см. предыдущие статьи). А вот теперь самое интересное — переходим к составлению плана внедрения регулярного менеджмента. Сразу оговорюсь, если в компании уже что-то существует в том или ином виде, работает и приносит пользу, — этот опыт учитывается при внедрении (для этого и собиралась подробная информация о текущем положении дел!).
3.2. Типовой план проекта внедрения регулярного менеджмента, или Долгожданная пошаговая инструкция
Перед утверждением любого плана действий важно помнить: успешность проекта внедрения регулярного менеджмента во многом зависит от оперативной корректировки как плана проекта, так и сценария внедрения на основе полученных в процессе действий фактов. Некоторые пункты могут выполняться параллельно, что показано на прилагающейся диаграмме Ганта (чтобы увеличить, щёлкните по ней мышкой).
Диаграмма ганта, на которой показан типовой план внедрения регулярного менеджмента.
Далее разбираем “по косточкам” каждый пункт плана.
1. Проектная команда изучает/штудирует книгу Александра Фридмана (от 2 недель)
Руководитель проекта и активные участники проектной команды должны проштудировать книгу Александра Фридмана “Вы или вас. Профессиональная эксплуатация подчиненных. Регулярный менеджмент для рационального руководителя”.
В процессе изучения книги читающие составляют (каждый в отдельном файле) список вопросов, добавляют в файл все спорные/непонятные/неочевидные моменты. Составляют краткий конспект с ключевыми моментами по каждой главе в электронном виде.
2. Проектная команда обсуждает свои вопросы и комментарии с консультантами по итогам прочтения книги (2 дня)
Руководитель проекта обсуждает прочитанное с командой, а потом отдельно с консультантами. Обычно в процессе осмысления информации из книги у руководителя проекта появляются предложения по дополнениям в план внедрения.
После чтения консультанты обязательно организуют “разбор полётов”. Прочитавшие задают уточняющие вопросы консультантам, заносят ответы в свои файлы (кстати, файлы потом складываются в единую папку, и становятся основой для базы знаний проекта), получают от консультантов примеры применения тех или иных механизмов регулярного менеджмента на практике.
Консультанты здесь нужны, чтобы “совместить” впечатление от прочитанного с реальным опытом внедрений и предостеречь как от чрезмерно оптимистических настроений, так и от возгласов “всё пропало”.
3. Запустить принудительный “апгрейд” всех управленцев (от 12 месяцев)
Управленцы выработают привычку подробно анализировать информацию и закреплять её с помощью ключевых тезисов.
Составить типовой план обязательного управленческого апгрейда для руководителей всех звеньев. Для каждого из них консультанты и руководитель проекта совместно составляют личный план изучения материалов. Человек не только должен их изучить, но и по каждому материалу сделать следующее: 1) создать себе “шпаргалку” в электронном виде с ключевой информацией; 2) выписать список вопросов, возникших в процессе изучения; 3) составить список предложений на тему “как можно использовать полученные знания в нашем отделе/компании”.
Не лишним будет подумать и о ценностях (работа с ними упоминаются в плане “апгрейда”). Ценности должны быть централизованно сформулированы для всей компании! У каждого отдела/подразделения могут быть дополнительные ценности, отражающие его специфику, но не противоречащие общим.
Например, одна из важнейших ценностей любого руководителя звучит так: “я несу полную ответственность за действия своих подчинённых”. Если для вас эта фраза звучит “ужасно”, то добро пожаловать в статью “Ответственность руководителя за действия подчинённых: «Почему же ты смотришь на соломинку в глазу твоего брата, а в своем глазу не замечаешь бревна?»”
Если ценности не сформулируете вы, то это сделают за вас сотрудники и исходя из своих интересов
Ценности – они такие. Если их не сформулируете вы, то сотрудники это сделают за вас и исходя из своих интересов. И только один вопрос останется: “Нужны ли, полезны это ценности для компании или вредны?” И если вы “прозевали” процесс стихийного формирования ценностей, то в дальнейшем вам придётся периодически сталкиваться с массой неприятных “правил обычая”, изменить которые можно, лишь применяя стратагемы и/или в процессе управленческой борьбы.
Что можно включить в план “апгрейда” управленцев и руководителей?
- Чтение книги Александра Фридмана “Вы или Вас” с таким же разбором прочитанного, как и для проектной команды.
- Действия по приведению всех поступков управленцев к сформулированным выше корпоративным “ценностям для руководителей”.
- Список книг, материалов, видео, семинаров, курсов и т.д. для развития управленческих компетенций (подробно про них — в статье “Ключевые компетенции руководителя для эффективного управления подчинёнными — «страшный» чек-лист для самопроверки и оценки”).
4. Пересмотреть старый и внедрить новый алгоритм поиска и подбора сотрудников (от 1 месяца)
При внедрении регулярного менеджмента один из основных рисков — это временный отток кадров, не всегда самых лучших, но бывают и исключения…. “Избалованный” хороший специалист может отправиться в поиске другого “тёплого места”, где по-прежнему можно заниматься очковтирательством, рыть “свой собственный пруд с мутной водой” и “золотыми рыбками”, делая свою работу непрозрачной, а себя — незаменимым.
Закон сообщающихся сосудов в действии, ведь водой и рыбками эти пруды будут наполняться за счёт вашего бизнеса.
К данной ситуации желательно подготовиться заранее: сформулировать принципы подбора персонала и разработать подробный регламент. HR’ы, безусловно, “будут рады”, ибо у них с этого момента заканчивается тихая и спокойная жизнь.
Предлагаю к прочтению две моих статьи в качестве подсобного материала для ревизии принципов подбора персонала:
- Про общие принципы подбора: “Руководители-соратники (управленцы и начальники всех уровней): ключевые принципы системы подбора и найма”.
- Алгоритм подбора, который можно использовать с минимальными модификациями “Пошаговый алгоритм поиска и подбора руководителей-соратников: где искать, и как проводить собеседование при приёме на работу”.
С чего начать наведение порядка и переход на системное управление? Пройдите индивидуальную диагностику своего управленческого стиля лично с Евгением Севастьяновым.
Стоимость: 9 970 р Бесплатно только 2 места до 22 мая 2023!
Узнайте на онлайн-встрече причину ваших проблем в управлении и сделайте так, чтобы сотрудники работали самостоятельно, качественно и без косяков.
5. Внедрить 7 парадигм регулярного менеджмента, или Сценарий первого “встречного боя” (от 4 месяцев)
Ну наконец-то и до рядовых сотрудников дошли. Проектная команда и консультанты потирают руки. Цель первого “встречного боя” (именно так, ибо ожесточенное сопротивление ожидаемо) — внедрить 7 парадигм регулярного менеджмента (см. список парадигм), а также систему принуждения к их выполнению. Отмечу, что кроме принуждения должны присутствовать также мотивация и поддержка от руководителя.
“Встречный бой” вполне может закончиться и “рукопашной” (в переносном смысле, естественно). Как правило сотрудники не хотят отдавать ни пяди своих прав на безответственность.
Суть работы по парадигмам следующий: любые действия сотрудников в рамках профессиональной деятельности оцениваются на основе парадигм регулярного менеджмента. В формализованном виде, естественно! Для этого необходимо завести электронное личное дело на каждого сотрудника с уровнем доступа: непосредственный руководитель + все вышестоящие руководители.
Предлагаю вам посмотреть видео-пример разбора реальной управленческой ситуации из моей личной практики. Наглядный пример как она разбирается с сотрудником и какая информация должна фиксироваться в личном деле. Ситуацию в примере я назвал “Блок питания — пожиратель рабочего времени”. Причина возникновения — бесполезно потраченный час рабочего времени одним из сотрудников. Смотрим и конспектируем.
Кто-то после просмотра видео может сказать “Ну просто смешно! Подумаешь, какая мелочь, – всего лишь 1 час рабочего времени и такой сыр-бор!”. Пожалуйста, это ваше право. Но хочу отметить один важный момент. По моему опыту, если руководитель разбирает правильно и подробно “мелкие” проступки своих подчинённых, то “крупные” случаются с гораздо меньшей вероятностью.
Видео-пример разбора управленческой ситуации №1: “Блок питания — пожиратель рабочего времени”
Наглядный пример разбора управленческой ситуации
В процессе внедрения парадигм без принуждение не обойтись, однако и о поддержке с мотивацией тоже забывать не стоит. Про мотивацию и поддержку я рассказывал выше, а также упоминал в предыдущих частях статьи. Сейчас, с вашего позволения, остановлюсь на принуждении.
Принуждение — мать учения, или Действенный метод профессионального роста “из-под палки”
Метод на самом деле прост. Из существующего оклада сотрудника выделяется премия за безупречность ~10% от оклада. Также параллельно возможно увеличение самого размера оклада в рамках привязки конкретного сотрудника к его достижениям в области использования регулярного менеджмента на практике.
Раз есть премия, значит, будет и депремирование. Какая же это премия, если она начисляется автоматически? Итак, необходимо ввести депремирование за однократное нарушение парадигм регулярного менеджмента — 10% от премии за безупречность (получается 1% от оклада). Депремирование может быть заменено на другое наказание из заранее составленного списка на усмотрение руководителя (замена не может осуществляться 2 раза подряд, т.е. за следующее нарушение — депремирование будет уже обязательным)
Холостой выстрел — действенная демонстрация ваших намерений и факта, что при необходимости выстрел будет настоящим.
Этапы внедрения системы депремирования
- Первый месяц (“холостые выстрелы”): факты нарушения парадигм регулярного менеджмента заносятся в электронное личное дело сотрудника, подробно разбираются, но депремирования не происходит.
-
Второй месяц (“выстрелы солью”): факты нарушений и проступков заносятся руководителем в личное дело и депремируются в размере 50% (т.е. вместо 10% премии за безупречность, вычитается 5%).
- Третий месяц и далее (“стрельба боевыми”): все факты заносятся в личное дело, размер штрафа составляет 10% от премии за безупречность.
Каждый месяц подводятся итоги (обязанности руководителя подразделения и службы HR, если таковая у вас есть). Количество и содержание проступков, за которые был выписан штраф — прямое свидетельство профпригодности сотрудников, наглядно демонстрирующее их истинное отношение к управленческой системе, к вашему бизнесу и к вам лично как руководителю.
Все “спорные” нарушения на первых порах имеет смысл обсуждать с консультантами, чтобы перенять у них опыт разбора управленческих ситуаций и проступков в рамках парадигм регулярного менеджмента (как вы могли посмотреть на видео выше, даже для мелких проступков требуется подробный разбор).
Личное дело сотрудника поможет вам “вспомнить” все его косяки и достижения, проследить вектор развития или его отсутствие.
Все комментарии, полученные от консультантов, должны фиксироваться в личных делах сотрудников, и, при необходимости, пополнять внутренние регламенты вашей компании. Следующий этап – запуск процесса разбора проступков силами проектной команды, а в дальнейшем — силами непосредственных руководителей.
Бонус для внимательных читателей: электронный шаблон-образец личного дела сотрудника с примером заполнения!
Хотите получить шаблон личного дела сотрудника в электронном виде, чтобы начать учитывать проступки, договорённости, достижения каждого?
Нужно выполнить 2 простых действия:
1) Оставьте комментарий к статье в самом низу, как на скриншоте: https://yadi.sk/i/QHQ2_R4oiWjkV (Напишите кратко о том, в каком формате вы сейчас ведёте историю договорённостей со своими подчинёнными. Согласны ли Вы, что это необходимо делать? Аргументируйте, пожалуйста, свой ответ). Вопросы в комментариях приветствуются.
2) Отправьте запрос на получение шаблона электронного личного дела через мои личные аккаунты в социальных сетях:
6. Составить список бизнес процессов, запустить их актуализацию, внедрить новые регламенты (от 4 месяцев)
Параллельно с внедрением парадигм регулярного менеджмента необходимо составить список ключевых и второстепенных бизнес-процессов, а также другой деятельности, которую необходимо формализовать.
Регламенты и правила делятся на два основных класса: управленческие (стандарты внутрикорпоративной переписки, требования к постановке задач, алгоритм подсчёта рабочего времени, регламент работы с проектами и т.д.) и рабочие (алгоритм продажи услуги/товара, инструкция по заключению договора, алгоритм работы с клиентской задачей и т.д.).
Хороший регламент словно “эликсир правды”, показывает истинную отношение к работе со стороны подчинённых
Имеет смысл составить также перечень существующих на данный момент регламентов, требующих значительной доработки (то есть неактуальных). Определить сроки внедрения для каждого нового регламента. Особенно обратить внимание на формирование базы знаний. Не забыть о регламентах по отслеживанию контрольных точек для руководителей.
В разработке регламентов активно принимают участие сотрудники, которых он непосредственно касается, и руководитель проекта внедрения регулярного менеджмента. На этапе утверждения регламентов сотрудники могут вносить предложения, дополнения, предлагать исключить или исправить тот или иной пункт и т.д.
Ввод нового регламента необходимо продумать не хуже, чем спуск на воду нового корабля.
Должна быть определена технология официального ввода в действие новых регламентов и дополнений к ним. Как дополнять регламенты? На основе практики применения и предложений сотрудников. Более подробно про регламентацию и её роль в эффективности работы компании, и как внедрить систему регламентов, рассказываю и показываю в моём мини-тренинге «Мастер регламентов».
7. Внедрить ежедневные планы и отчёты для сотрудников (от 2 месяцев)
Ежедневные отчёты и планы имеет смысл внедрять в несколько этапов (каждый следующий этап дополняет предыдущие):
- Первый (длительность: 2 недели): сотрудники обязаны фиксировать в отчётах пять наиболее крупных выполненных задач с указанием времени на каждую из них.
- Второй (длительность: 2 недели): сотрудники обязаны фиксировать в отчётах все задачи с указанием затраченного времени.
- Третий (длительность: 2 недели): сотрудники должны составлять план работ на каждый день и оценивать планируемое время на выполнение задачи.
Подробно про планы и отчёты я рассказал в статье “Ежедневный план и отчёт: Как организовать, чтобы сотрудники сами планировали свой рабочий день”.
8. Организовать развитие регламентов и базы знаний силами сотрудников на постоянной основе (от 2 месяцев)
Запустить процесс обновления регламентов и пополнения базы знаний силами сотрудников и руководителей, отвечающих за их выполнение. В помощь статья “Попробуй заставить меня написать регламент!» или Алгоритм по написанию регламентов: как делегировать разработку инструкций своим подчинённым”.
9. Организовать дальнейшее развитие регулярного менеджмента в компании силами сотрудников на постоянной основе (от 2 месяцев)
По итогам предыдущих этапов в компании останутся люди, которые действительно разделяют ценности регулярного менеджмента и отчётливо понимает их преимущества, как для себя лично, так и для компании.
В данной ситуации управленцы тоже будут с удовольствием участвовать в дальнейшем развитии технологий регулярного менеджмента. Подробнее про преимущества системы регулярного менеджмента для руководителей всех уровней и рядовых сотрудников читайте в статье “Руководители-соратники (управленцы и начальники всех уровней): ключевые принципы системы подбора и найма“.
3.3. Ресурсы проекта: потребуются время, деньги и умение “держать цель”
Основные ресурсы проекта — время сотрудников и деньги. Типовая ошибка — запустить проект, но при этом не запланировать и не выделить для руководителя проекта и его команды отдельное время на реализацию. Мол, сами как-нибудь найдут. Возможно и найдут, но наверняка по остаточному принципу.
Пример из моей практики. Владелец одной компании не мог со мной созвониться по вопросу внедрения регулярного менеджмента в течении одного месяца, так как у него банально не хватало времени, — “погряз по самую макушку” в оперативке. И после того, как он всё-таки нашёл время для беседы, я любезно взял самоотвод. Так как результат такого серьёзного проекта при отсутствии времени гарантированно предсказуем – это провал.
Время может похоронить любой проект. Как до старта, так и после.
И, конечно же, потребуются деньги. Во-первых, необходимо учесть, что сотрудники из проектной команды тоже получают деньги за свою работу (зарплату). Посчитать затраты на их вознаграждение просто: стоимость одного часа помноженная на количество затраченных часов (плановый бюджет сами догадаетесь, как рассчитать?).
Кого-то из сотрудников придётся нанимать, кого-то увольнять (это тоже затраты). Возможно, потребуется купить дополнительное программное обеспечение. Может быть, приобретать его не придётся, если ваше существующее справится со всеми задачами. В конце концов, бюджет на оплату работы консультантов также потребуется.
Хороший план актуализируется в процессе выполнения, плохой — замораживается и принимается за догму
Поэтому обязательные составляющие в детальном плане проекта — ориентировочный бюджет на каждый этап и планируемое время на выполнение по каждому исполнителю и подразделению. Сразу скажу, повесить на стену распечатанный план не получится, ибо события в процессе внедрения обязательно внесут в него существенные корректировки. Но об этом вы догадываетесь и без меня 🙂
После каждой вехи (ключевого этапа из плана) проекта обязательно подведение промежуточных итогов (иногда для этого важно организовать живую встречу всех участников: собственников, консультантов и руководителя проектов), подсчёт затраченных ресурсов, разбор возникших сложностей, корректировка, дополнение и актуализация плана проекта на основе опыта предыдущих этапов.
Правильно говорят: двух одинаковых компаний (бизнесов) не бывает. Одни и те же действия в одних компаниях выполняются за пять дней, а в других — за пятьдесят. Компании отличаются не только количеством сотрудников, но и стартовыми условиями, а именно состоянием действующей системы управления.
3.4. Риски проекта (“пропустить нельзя просчитать” — где бы вы поставили запятую?)
Когда составлен подробный план, приходит время проработать и риски с особой старательностью и углублением в конкретику. Правильно сделать и SWAT-анализ, но в эту тему углубляться не буду. Кстати, подробное описание технологии работы с проектами вы можете найти в книге Михаила Рыбакова “Как навести порядок в своём бизнесе”, читайте подробный обзор “Трансформируйте свой бизнес в систему — книга Михаила Рыбакова «Как навести порядок в своём бизнесе»”.
Риски существуют в любом деле, рекомендую учесть и просчитать их заранее. Тогда и соломку можно успеть подстелить.
Риски, которые важно учесть, разделены на группы
- Внутренние: “избалованный” персонал, отсутствие терпения у собственника, “неквалифицированный” персонал, негативная реакция ключевых сотрудников, нехватка времени на проект у участников.
- Внешние: рынок требует более решительных, активных и немедленных действий (актуально, если компания находится в состоянии “комы”).
- Финансовые: проект “заморожен” или возникли перебои с финансированием внедрения; выход за рамки бюджета проекта.
- Юридические: отставание юридического оформления от вводимых изменений (возможно, потребуются новые трудовые договоры, графики работы и т.д.).
- Связанные с персоналом: отток персонала (подробно разбирался в предыдущих частях), отсутствие “запасных игроков”, замена ключевого игрока в проектной команде и т.д.
- Технологические: отсутствие компетенций сотрудников компании для выстраивания it-инфраструктуры под регулярный менеджмент, желание использовать “старые” системы “любой ценой” и т.д.
Этап №4. Выполнить работы по внедрению регулярного менеджмента, взаимодействие в проекте, роль консультантов
Хороший план — залог успеха. Дальше остаётся лишь действовать на его основе и актуализировать план в зависимости от “обратной реакции” на действия. А насколько будет “обратная реакция” влиять на корректировки плана, зависит от ранее (до старта внедрения) существовавших в компании корпоративных ценностей и системы управления (важно отметить, что традиции в разных подразделениях и “право обычая” свои). Именно поэтому и не бывает двух одинаковых внедрений.
Теперь подробнее о роли консультантов на этапе внедрения. Напоминаю, что они играют роль “фанатов проекта” и являются основными защитниками от риска “профанация идеи”.
Роль консультантов — помочь сохранить эффективность текущей деятельности компании на время внедрения регулярного менеджмента.
Список функций консультантов в проекте внедрения регулярного менеджмента
- Предварительное обсуждение плана действий для конкретного подразделения и планируемых к использованию технологий с командой проекта.
- Помощь в преодолении возникающих препятствий и разборе нестандартных ситуаций с командой проекта, обучение команды проекта решению их самостоятельно в будущем.
- Промежуточный и финальный контроль соблюдения ключевых принципов регулярного менеджмента, недопущение компромиссов “да ладно, и так сойдёт”.
- Взаимодействие с командой проекта через конференции скайп и другие средства коммуникаций. При необходимости участие во встречах в офисе.
Отсюда следует: чем лучше у вас состояние дел в компании сейчас, чем квалифицированней команда внедрения как управленцы, чем больше консультанты вкладывают в обучение проектной команды, тем дешевле вам обойдётся внедрение регулярного менеджмента и дальнейшая его поддержка.
Отчётность и формализация, как технология сохранения информации
Вся работа по проекту должна быть максимально формализована. Все запросы к консультантам письменно фиксируются, как и ответы на них. С одной стороны, такой подход в тактическом смысле увеличивает расходы на консультантов. С другой (куда более важной) стороны, в стратегическом смысле для вашей компании создаётся база знаний по внедрению и использованию регулярного менеджмента, а также по разобранным управленческим ситуациям. В некоторых случаях даже видео-уроки записываются.
Это позволит сэкономить как значительные средства на работе консультантов в дальнейшем, так и избежать зависимости (устранение незаменимости отдельных звеньев — это один из ключевых факторов стабильного развития бизнеса) от руководителя и проектной команды внедрения регулярного менеджмента.
Тот кто пренебрегает внешними консультантами может оказаться в той же ситуации, как человек на качелях с картинки.
В оговоренном уставом проекта формате и с заданной периодичностью консультанты совместно с руководителем проекта готовят отчёт о проделанной работе. Как правило, в нём фигурируют: результаты за отчётный период; сравнение с предыдущими периодами; подведение промежуточных итогов по всему проекту; актуализация этапов и календарного графика проекта; наиболее значимые события за отчётный период; актуализация прогнозов по рискам.
Отдельно консультанты (как фанаты проекта) готовят свой индивидуальный отчёт: выносят на обсуждение возникшие и нерешённые разногласия с руководителем проекта (если таковые имели место).
За рамками Этапа №4, или Ответы на часто задаваемые вопросы
IT-инфраструктура для внедрения регулярного менеджмента? Где брать?
Назрели вопросы: А какое нам программное обеспечение потребуется для работы регулярного менеджмента? А подойдёт ли старое? А нужно ли будет что-то докупать? А что, если наши сотрудники не работают за компьютером?
Намеренно оставил за рамками статьи детальной подбор информационных систем для автоматизации перечисленных действий, и вот почему.
Друзья, регулярный менеджмент — это технология, и значит, она имеет множество способов воплощения, начиная от листов бумаги и карандаша и заканчивая современными ERP-системами. Выбор способов зависит от особенностей компании (сфера деятельности, масштаб, ресурсы). Важно другое: если в вашей компании бардак, то, установив всевозможные системы, на выходе вы получите автоматизированный бардак и не более того.
Я уже рассказывал в “Этапе №1”, что единственное требование к IT-инфраструктуре — решение задач регулярного менеджмента на текущий момент и на перспективу. Точные выводы о возможности использования конкретного программного обеспечения можно сделать только после его детального изучения.
Почему в плане фигурируют только ежедневные планы и отсутствуют стратегические?
Стратегические планы останутся только планами, если никто не планирует свой рабочий день. Следствие: сложная задача скорее будет выполнена с неудовлетворительными результатами, если даже маленькие задачи не выполняются с заданными параметрами качества. Нужны ли вам более убедительные доводы? Я подготовил их для вас.
Принцип домино актуален и для задач. Одна неверно выполненная может “завалить” весь проект.
Предположим большая задача состоит из 30 (тридцати) маленьких подзадач. Не такая уж и большая задача, не правда ли? Если вероятность выполнения каждой маленькой подзадачи 99%, то какова будет вероятность выполнения целой задачи? 74%! А если таких составных задач не 30, а 120 (в этом случае вероятность выполнения целой задачи будет всего лишь 30%)? И в заключение вопрос: А Вы уверены, что вероятность правильного выполнения маленькой задачи в вашей компании 99%?
Да, безусловно, необходимо внедрять и ежемесячные планы, и планы по всем существующим внутренним/внешним проектам, и стратегические планы развития тоже. Однако, когда у вас в компании внедрён регулярный менеджмент, появляется возможность эффективно и быстро внедрять и, самое главное, в дальнейшем эффективно использовать любые технологии, которые вы сочтёте полезными.
Два больших плюса при внедрении любой новой технологии, когда у вас уже есть регулярный менеджмент:
- Значительное сокращение издержек на внедрение технологии. Нет бесконечных “пробуксовок”, саботажа, профанации, ибо те, кто обычно этим занимается, теперь прекрасно осведомлены, что любые их действия будут прозрачны для менеджмента.
- Гораздо больший шанс, что технология будет реально использоваться сотрудниками в работе. Часто приходится слышать от собственников “у нас есть вот эта супер-технология”, а когда начинаешь смотреть ближе, выясняется, что технология-то есть, но никто её не использует! При этом, если технология “неэффективна”, то в рамках регулярного менеджмента она “отклоняется” системой управления (а не потому, что сотрудникам лень выполнять новые правила, или они не считают нужным это делать).
Этап №5. Завершить проект внедрения регулярного менеджмента. Перевести проект в программу: закрепить и поддерживать результаты, развивать силами сотрудников
Успешное завершение проекта внедрения регулярного менеджмента определяется наступлением следующих событий:
- Достигнуты цели, поставленные перед стартом проекта.
- План проекта выполнен с отклонением по времени и бюджету в рамках допустимых (параметры отклонений определяются индивидуально для каждого проекта).
“Запечатать” и положить в архив проект не выйдет. Для того, чтобы изменения остались в силе необходимо трансформировать проект в программу.
Хорошо, предположим, всё завершилось успешно, все в компании работают по регулярному менеджменту, но остаются важные вопросы: Как сделать, чтобы новые сотрудники приучались к регулярному менеджменту? Как сделать, чтобы “всё не вернулось на круги своя” через некоторое время X? Увы, ответ будет неутешительный. Любая система требует постоянной поддержки и дальнейшего развития. И управленческая система на основе регулярного менеджмента — не исключение.
Консультанты — важнейший ресурс для собственников и руководителя программы по поддержке и развитию регулярного менеджмента
Для поддержки и развития регулярного менеджмента сразу после завершения проекта внедрения стартует бессрочная программа по поддержке и развитию регулярного менеджмента. Создаются специальные управленческие чек-листы, выбирается период для контрольных точек. Программу должен возглавить человек из компании, который будет назначен ответственным за неё (часто руководителем программы становится руководитель проекта внедрения регулярного менеджмента или наиболее активный член команды проекта).
Работа в формате программы выходит за рамки цикла статей. Добавлю только одно: консультанты — важнейший ресурс для собственников и руководителя программы. Для первых — это возможность внешнего контроля и независимость от персонала, для вторых — возможность совместно решать сложные задачи и быть более эффективными за счёт минимизации вероятности серьёзных ошибок и просчётов.
На развилке дорог, или Вместо заключения
Ещё раз напоминаю, что у вас есть выбор: всё делать самим или подключить консультантов с практическим опытом внедрения регулярного менеджмента.
На первый взгляд обе дороги видятся равноценными, однако…
“Лёгкая прогулка” на этом проекте не предвидится. Отнюдь, на горизонте просматриваются: саботаж многих сотрудников, возникающие нестандартные управленческие ситуации и большое количество времени, сил, энергии, которые необходимо потратить на внедрение регулярного менеджмента. И если не “дожать” даже чуть-чуть, то вся работа пойдёт насмарку.
Моя позиция однозначна — без консультантов идея регулярного менеджмента имеет большую вероятность быть “профанированной”. При этом хорошие консультанты сэкономят на порядок больше ваших денег, чем вы потратили бы на обнаружение граблей на пути внедрения регулярного менеджмента. Не верите? Пишите и звоните, с удовольствием отвечу на ваши вопросы! 🙂
Ключевые принципы работы консультантов “Открытой Студии”
- Решить вопрос необходимо так, чтобы у Клиента появилась технология, которой он может пользоваться без помощи консультантов.
- Чтобы принять правильное решение, необходимо отличить “факты” от “мнения о фактах”. А для этого нужно задавать много вопросов и уделять скрупулёзное внимание мелочам.
- Мы подчиняемся только одному человеку — собственнику компании, и работаем на него и для него, в соответствии с его целями.
Содержание
- 1 Создание, документирование и выполнение плана по внедрению
- 1.1 Подходы по созданию плана внедрения
- 1.2 Создание плана внедрения
- 1.3 Документирование
Создание, документирование и выполнение плана по внедрению
Эффективный документированный план по внедрению – это результат правильно выполненных процессов и процедур на этапах планирования, развёртывыания и тестирования.
Подходы по созданию плана внедрения
- Ad hoc (с лат. к этому, для данного случая, для этой цели) – большинство задач, таких как внедрение нового оборудования, подключение, адресации, маршрутизации и обеспечение политик безопасности выполняются в соответствии с требованиями, но без планирования любой из задачи. При таком подходе, скорее всего, возникнут проблемы с масштабируемостью, неоптимальными маршрутами в сети и безопасностью. Правильный план внедрения нужен, чтобы избежать таких проблем.
- Структурный подход (Structured Approach) – При этом подходе сетевой инженер определяет потребности сети при модернизации (например, внедрение нового протокола маршрутизации) и начинает с первого этапа – планирования. Основываясь на существующей топологии проверяются все потенциальные изменения, многие соображения принимаются во внимание. Этап проектирования и план по внедрению завершены. Они могут включать новую топологию, план по IP-адресации, решение проблем с масштабируемостью, оптимизации использования канало и изменений других параметров сети. Проект и план должны отвечать как техническим требованиям, так и бизнес-требованиям компании. Все детали отображаются в плане до непосредственной реализации. После успешного развёртывания, документация обновляется в соответствии с результатами и используемыми инструментами.
Многие модели и методики, используемые в ИТ, определяются lifecycle-подходом, использующие различные процессы для обеспечения высококачественных ИТ-сервисов. Развёртывание сети (network implementation), включая план внедрения, – всего лишь одна часть таких моделей. Вот некоторые примеры таких моделей (не изобретайте велосипед!):
- The Cisco Lifecycle Services (PPDIOO) model – определяет минимальный набор действий, необходимых для помощи заказчику успешно развернуть и использовать технологии Cisco, оптимизировать её производительсность на всё жизненном цикле сети. Состоит из 6 фаз:
- Prepare (подготовка)
- Plan (планирование)
- Design (проектирование)
- Implement (внедрение)
- Operate (эксплуатация)
- Optimize (оптимизация)
- IT Infrastructure Library (ITIL) – библиотека инфраструктуры информационных технологий) — библиотека, описывающая лучшие из применяемых на практике способов организации работы подразделений или компаний, занимающихся предоставлением услуг в области информационных технологий. В семи томах библиотеки описан весь набор процессов, необходимых для того, чтобы обеспечить постоянное высокое качество ИТ-сервисов и повысить степень удовлетворенности пользователей.
- The Fault, Configuration, Accounting, Performance, and Security (FCAPS) model – модель Международной организации по стандартизации (ISO), в которой отражены ключевые функции администрирования и управления сетями:
- (F) Fault Management / Управление отказами – Компоненты Fault решают задачу выявления и устранения сетевых проблем, ведут обработку аварийных сообщений и системных прерываний, опрос элементов сети, тестирование и диагностику.
- (C) Configuration Management / Управление конфигурацией – осуществляются мониторинг и контроль аппаратного и программного обеспечения сети и любой их модификации.
- (A) Accounting Management / Учёт – отвечает за распределение и надлежащее использование сетевых ресурсов.
- (P) Performance Management / Управление производительностью – представление статистики работы сети в реальном времени, минимизация заторов и узких мест, выявление складывающихся тенденций и планирование ресурсов для будущих нужд.
- (S) Security Management / Управление безопасностью – обеспечивает контроль доступа, ведение журналов доступа, защиту от внешних и внутренних нарушителей.
- The Telecommunications Management Network (TMN) model – похожа на FCAPS. ITU-T взял основные положение FCAPS и создал свой фреймворк. План по внедрению и внедрение одни из основных блоков в фреймворке. Концепция, разработанная и утверждённая Международным союзом электросвязи, определяет принципы создания единой системы управления для сетей разных уровней и масштабов, предоставляющих различные типы услуг. Возможность применения такой системы управления связана с отсутствием жёсткой привязки TMN к какой-либо транспортной системе и особенностям конкретной сети. Вся необходимая для управления информация располагается в единой базе данных, которая может изменяться и пополняться описаниями новых объектов управления, а весь обмен служебными данными TMN может осуществляться с использованием существующей транспортной системы управляемой сети. Основная идея концепции TMN — обеспечение сетевой структуры для взаимодействия различных типов управляющих устройств и телекоммуникационного оборудования, использующих стандартные протоколы и стеки.
Модели должны выбираться организацией исходя из потребностей. Различные модели могут комбинироваться и адаптироваться под задачи. Это позволит осуществить эффективное внедрение технологий Cisco.
Создание плана внедрения
Методика проектирования (creating an implementation plan), при использовании модели PPDIOO, содержит три основных шага:
- Шаг 1. Определить потребности заказчика : на этом шаге, который выполняет на этапе Prepare, целью принимающего решение является понять начальные бизнес и технические потребности. Основываясь на них предлагается концептуальная архитектура.
- Шаг 2. Характеризовать существующую сеть и сайты (sites) : на этом шаге, который выполняет на этапе Plan, проводится аудит (качество и целостность) и анализ сети (например, трафика) с целью определения возможностей сети к реализации предложенного решения.
- Шаг 3. Проектирование сетевой топологии и решений : на этом шаге, который выполняет на этапе Design, создаётся детальный проект сети. Принимаются решения о сетевой инфраструктуре, сервисах и приложениях. Данные для реализации шага собираются на предыдущих шагах. Может быть собран прототип сети для проверки корректности проекта перед внедрением. на этих шагах в результате должен быть написан подробный документ, содержащий информацию, полученную на всех шагах.
Когда этап проектирования (Design) выполнен, переходим к выполнению процесса проектирования внедрения (the design implementation process), который включает 3 шага:
- Шаг 1. Планирование внедрения (Plan the implementation): На этом этапе план по внедрению подготавливается заранее, чтобы ускорить и уточнить фактическую реализацию. Так же в это время проводится оценка стоимости. Шаг выполняется на этапе Design.
- Шаг 2. Внедрение и проверка проекта (Implement and verify the design): Этап Implement.
- Шаг 3. Мониторинг и опциональный редизайн (Monitor and optionally redesign): Сеть запускается, мониторится и проверяется на ошибки. Если ошибок много или их даже невозможно решить, то проводится редизайн (если требуется). Это на шаге Operate и Optimize.
Таким образом, процесс создания плана по внедрению – это часть фазы проектирования. Перед разработкой плана по внедрению, вы должны идентифицировать следующую информацию:
- Информацию о сети, необходимую для разработки плана – существующая топология, оборудование, версии ПО, план адресации, требования для масштабирования (суммирование, stub-зоны и т.п.), список анонсируемых сетей, link utilization, требуемые метрики для основных и резервных каналов. И другие требования, типа инструментов, специальных команд (для конфигурирования и проверки), которые могут быть использованы.
- Зависимости с другими сервисными компонентами и существующей сетью, который имеет ваш план по внедрению – риски по внедрению должны быть известны.
- Рекомендуется ресурсы для выполнения мероприятий и задач, связанных с разработкой плана реализации – график внедрения, роли и отвественных за ресурсы необходимо задать.
Основываясь на собранной информации, сетевой инженер определяет необходимые задачи для внедрения. Например, дизайн топологии или адресацию или другие требования к существующей сети. После разработки плана, решение внедряется и проверяется, а документация актуализируется.
Следующие шаги выполняются в течении создания и выполнения плана по внедрению:
- Planning the implementation – планирование внедрения
- Selecting the tools and resources required – выбор инструментов и ресурсов
- Coordinating work with specialists – координированная работа со специалистами
- Verifying the implementation – проверка
- Interpreting performance results – интерпретирование результатов производительности
- Documenting the baseline, performance, and recommendations – документирование и рекомендации
The tasks in a site-specific implementation plan may include the following:
- Определение приложений и устройств, необходимых к внедрению
- Создание installation tasks и checklists
- Определение конфигурации устройств и требований к ПО
- Создание site-specific конфигураций устройств, installation tasks, and checklists
- Сreating installation verification tests
Документирование
Документация должна быть верной и актуальной, т.к. это необходимо при внедрении и проверке. После внедрения все шаги по проверке должны быть отражены в документации, так как это, возможно, поможет при решении каких-либо проблем, модернизации и изменениях в сети.
Документация должна быть доступной (например, для инженеров), содержать всю текущую информацию об оборудовании и конфигурации, и включать в себя информацию об известных проблемах и т.п.
Документация должна включать:
-
- Информацию о сети
- необходимых инструментах (tools) (например, tftp-сервер, консоль, консольный кабель, кабель Ethernet
- Требуемых ресурсах
- Implementation plan tasks
- Verification tasks
- Измерениях производительности и результатах
- Фото и скриншоты, если необходимо.
Создание документации не заканчивается до момента окончание проекта, когда будет добавлена инфа о проверке.
