📜 ⬆️ ⬇️

Scott Berkun - The Basics of Project Management

In the run-up to the seminar of Edward Yordon (the one who wrote “The Way of Kamikazes”), I decided to recall and systematize the previous “It-online” seminar on project management. I'm talking about Scott Burkun 's Basics of Project Management (April 25, 2007).

About Scott Berkun
Scott worked at Microsoft as a project manager such as: IE (first to fifth version), MSN and Windows. Sublimating his experience, he wrote the book The Art of IT Project Management. He is currently an independent project management consultant.

House Scott is located in a forest in the neighborhood of Sietla. Naturally, this interesting fact was several times the focus of the seminar participants. For example, there were such questions as: “How do you see the Russian IT market from the forest” =).

Seminar "Fundamentals of Project Management"
Part 1. Planning and task setting
At the beginning, a horror story was proposed to the public - statistical information from research in the USA: 50% of projects are 2 times more expensive than planned, 30% are minimized and only 16% are completed on time and within the allocated budget. The main reasons for this are that initially there is no clear vision (the goal is not described), the estimates are too optimistic (re-evaluation of resources). In addition, the risks are not taken into account: errors, changes, hospital, etc.
')
Separately, Scott highlights the fact that when the initial task changes, they do not take into account the change in the required resources. A project is an interconnected system of 4 variables - time, money, product quality, and project objectives. If we change one variable change and all the others (this fact is extremely important when communicating with the customer of the product). Therefore, speaking of planning, Scot drew attention to the fact that a good project plan should always be flexible, and therefore relevant for the current situation.

Describing the planning process, Scot proposed the following model:
The planning process described above was presented by Scot as a pyramid at the base of which there is a vision, and on top of that are specific types of work. If you need to make changes to some element, then the whole pyramid will change above.

Representatives of all areas of the project — the customer (possibly through the RP), the marketer (sometimes he is the customer, has knowledge of the market needs), the developer, the tester, the usability specialist (in this context are more than an ergonomist, because he has knowledge about user needs). In the process of generating documentation, the RP is a person who has knowledge of the whole picture, connects the customer and the development and approves the final version. For the success of the project, it is important that a limited number of people participate at this stage, as there is a need for discussion. The leading and unifying function of the RP is extremely important.

Vision and goals need to be described most specifically. For example, not “to improve the software product”, but “to satisfy the needs of the 5 largest clients”, not “to improve usability”, but “to improve usability through the 5 most frequently used tools”

Part 2. Project progress
In the previous part, I turned to the project planning and task setting reviewed by Scott Berkun in the seminar "Fundamentals of Project Management." This post, I systematized information on the management of the project.

First we turn to how Scott describes the project. According to him, almost every project with tight deadlines develops in steps. Initially, the work schedule (Y-scope of work, X-time) looks like a straight line segment: leaving the point with the maximum scope of work and the project start time, ending at the point when all the work has been completed and the time has been completely spent. But since, as it was written earlier, when planning does not take into account risks and changes, the schedule of work begins to lag, and in order to return to the planned course of work, it is necessary to abandon part of low-priority tasks or in other words reduce the amount of work. The task of the ER is to clearly understand the priorities of the tasks performed and to prevent such situations.

It should be noted that the later changes are made, the more expensive they are for the project. An extensive code has already been written to the “ensemble” (project completion period) - this means that you may have to abandon a lot of the work done. Problems if they are hidden deep, may entail a complete abandonment of the project. In addition, testers have completed work with simple elements and have begun to search for complex bugs. It is also not encouraging that people tend to put everything off for later, and at the end of the project they have to pay for it.

Scrum meeting
In order to keep abreast of and respond to a changing situation in time, weekly (or more often) meetings of volunteers are held. At these meetings, representatives of the working groups share their vision of the current situation, which may threaten the implementation of the project. Also at this meeting, based on the current situation, they correct the vision, goals, characteristics (specifications) and types of work on the project. Thanks to these flyers, the project develops with iterations similar to extreme programming .

The meeting is necessarily led by a responsible officer, usually a PM. The most effective meetings are held with not a large number of participants. Separately, Scot drew attention to the fact that for all the usefulness of quick bills, there are very “boring” and unhealthy meetings that must be avoided and certainly not initiated. Scott described some of the options for holding such meetings, for example: Scrum * . At such a meeting, only 4-5 issues are discussed, each participant speaks for 10-15 minutes. It is impossible to dissipate - only the questions that will help to realize the project are discussed: “What prevents to move to a new stage?”, “How to eliminate the cause?”, “What do you need to finish on time?”

3 lists
Since the RP is faced with the problem of choosing the most priority tasks. Reviewed earlier lists of goals, characteristics and types of work, Scott proposes to organize the lists with the division by priority. This will allow you to visualize the relationship between goals and work, and grouped by importance. In other words, it becomes clear what needs to be accomplished to achieve a specific goal.

Goals

High priority
Medium priority
Low priority
Specifications

High priority
Medium priority
Low priority
Types of jobs

High priority
Medium priority
Low priority

Making changes to the project
From the previously considered it is necessary to remember that any change in the project entails a change. If necessary, carry out additional work always:
Thus, the introduction of major changes (more than 4 man-hours) is a very important decision. Scott suggests using the Change Request document. It contains the necessary labor, financial costs and reasoning for change.

There must be a responsible officer who collects information and creates a request provided by the RP. RP, if necessary, attracts representatives of the project team (testers, developers, marketers ...), decides on the implementation of the request and notifies stakeholders.

Method of labor costing
At the workshop, Scott proposed a 2-nd version of the project labor cost estimate.

The first is based on pessimistic, realistic and optimistic evaluation options. Optimistic option - without taking into account possible risks. Realistic - the most likely risks are taken into account. Pessimistic - all risks are considered, including the unlikely ones (the risks must be realistic).

The real score is obtained by the formula:
(Optimistic var. + 4 * Realistic var. + Pessimistic var.) / 6

For pessimists =) there is a separate formula:
(Optimistic var. + 4 * Realistic var. + 2 * Pessimistic var.) / 7

Group assessment method
To estimate was more correct apply the group method. This method is based on an iterative approach. At the beginning, all the participants of the working group (4-5 representatives of developers and their managers) write down a pessimistic, realistic and optimistic assessment option. After that, the data is sounded and displayed on the board (white whiteboard, Scott's favorite tool).

Ivan30 days 50 days 70 days
Olga40 days 60 days 70 days
Peter45 days 60 days 80 days

The resulting numbers are argued by the participants. After that, the next stage of the closed assessment is carried out. At the last iteration, the data is averaged and the PM makes the final decision.

It should be noted that in a group assessment, employees learn to evaluate from more experienced colleagues.

When planning work, you must remember about the hospital, holidays and days off. In addition, according to statistics, an employee will not be able to work all 8 hours a day. He needs time to discuss current issues with employees, time for other tasks outside the project. According to statistics in the US, 30% of working time employees work alone, 50% communicate on work issues with another employee, 20% communicate on work issues with other employees in groups (meeting).

Decision making method
  1. In the beginning, it is necessary to clearly understand what is being decided;
  2. What are the alternatives?
  3. Analyze + and - each alternative;
  4. Skeptical and critical analysis of alternatives. What happens a week after the decision.
  5. Decision-making;
  6. Execution of the decision;
  7. Analysis of the decision. If a mistake is made, analyze how it could have been avoided.
It is extremely important to understand how the question on which the decision is made actually sounds. For example.
Question: "Do I need to outsource the development?"
It can mean: “It is necessary to achieve the highest efficiency” or “It is necessary to unload programmers” or “It is necessary to develop a product with the highest quality”.

At the first stage it is important to understand which decisions are important, and which ones do not need to waste time. Since the RP works in a constant shortage of resources and it is constantly under pressure from requests, demands, proposals. According to Scott, this is the main task of the RP - to be able to determine what is important and what is not for the success of the project.

After determining the true sound of the question and prioritization, it is necessary to collect 5-4 variants and write out for each of its pros and cons. By the way, the option “Do nothing” is also considered along with others. A critical approach to alternatives, sound skepticism and impartiality is very important.

In some cases it is useful to test alternatives., Create a prototype.

Since the reasons for which the decision was made are very important, it is necessary to somehow store this data. Scott suggests the following table:

OptionFor (+)Vs (-)Rating (priority)
A
B
Nothing to do

It is necessary to say a few words about the first version of something. To make a decision it is necessary to investigate the problem. What the user is facing. Identical sentences. Similar product category.

Project crash
If the collapse of the project is inevitable, the following options are possible:
  1. Change of project goal;
  2. Cancellation of the project;
  3. Slow down and think about follow-up actions (change the goal, cancel the project and analyze errors);
  4. Do nothing and enjoy disaster (not a good option);
  5. Pretend that such a project finale was conceived (a bad option, but people tend not to admit their mistakes);
  6. To accelerate the crisis (in some cases this option is the best).

Part 3. Team Management
In the previous parts of “Project Planning and Task Setting”, “Project Running”, Scott has already addressed the team involved in the project. Now consider this question in more detail.

Initially, Scott proposed two management options - 1. dictatorship (the manager tells subordinates what to do, management is based on unshakable authority) 2. communication (the manager helps in the best way to solve the task, explains how to do better, the manager unites intellectuals around the idea). Communication is not what I say, but how they understand me.

It is important to create an active communication. It is important that employees perceive the RP as an assistant. It is important that employees not only understand what task they should work on, but clearly link their work and the specific goal of the project.

How can this be achieved. Scott recommends that at the beginning of the working day you should look into the office to the developer and clarify: What is the employee doing? Any difficulties and threats for the project? How RP can help in their decision? A good idea to drink coffee together. It is important to be interested in the opinions and work of the staff involved in the project.

If an employee wants to make a decision, it is necessary to explain to him that input information is necessary for the correct decision. The collection and analysis of which will take time, a lot of time. For example, a meeting with the customer, coordination with the investor, etc.

It is very important that project participants clearly understand who is responsible for what. It is better to allocate areas of responsibility in advance, but if there is a problem, you need to sit down and jointly fill in the following table:

ITogetherEmployee
I am writing a specification
...
...
...
I'm writing code
Correcting bugs ...

A good solution would be to hang the table in a visible place.

At the stage of forming a team, you need a directory management, then you just need to direct the work. It is important (as stated above) to create a situation where each team member understands which goal is currently being realized.

At the end of the seminar, Scott spoke about a curious study. If you enter into the project change begins a zone of chaos. Even if the change is ultimately positive, there may be fluctuations in the effectiveness of the team. This happens because people get used to the new, learn, customize communications. The task of the RP to minimize the period of chaos (uncertainty).

When allocating new resources, the period of chaos must be taken into account. Therefore, the return from new employees will not be immediately (possibly after the end of the project).

RP issues for every day
  1. What can go wrong? What things are likely to go wrong?
  2. What can be done to warn them?
  3. What alert sensors can we build into the system?
Answers to these questions can be obtained from the team. It is important to be open and able to perceive information. When it is important to remember that not every mistake is the error itself, perhaps it is a symptom of a deeper problem. You must be able to highlight the main problem and be able to prioritize the list of problems.

Scott emphasizes that an employee responsible for the problem is needed to solve any problem. But in any case, the RP controls the solution to the problem.

If a problem occurs, you can not shout need to find a solution. You must ask the question: "What should be done so that the problem does not happen again?"

The composition of the team IE 1st version (in 1994)
1 RP 10-15 employees
5-6 programmers
3-4 testers
2 technical writers

The composition of the command IE 3rd version
2 RPs for 40 employees

Composition team IE 4th version
25 RP with 200 employees

* A slight digression about Scrum meetings
Such meetings of the synchronization of the work of the team are called differently. Daily Scrum Meeting, stand-up meeting, sometimes just a Status Meeting. In Luxoft called Daily Scrum or just scrum. The main goal of the scram is to synchronize the work of the team and minimize the waste of time associated with the lack of awareness of the team members. Each team member should be aware of what other people are doing and understand what the ultimate goal of the project is.

I have found other descriptions of Scrum meetings (for example, Askhat Urazbaev): a daily (usually morning) meeting lasting 10-15 minutes. Moreover, the meeting is not intended to solve problems in the project. All issues requiring special discussion should be moved out of the meeting.

Each meeting participant answers 3 questions:
  1. What was done yesterday?
  2. What will be done today?
  3. What problems did you encounter?
Examples of bad scram:
Because of the above, it is often the case that meetings are heavily delayed. As a result, they turn into daily problem solving meetings. Interest in scram immediately falls, the feeling of its usefulness disappears.

How to deal with the wrong course of scram:
ProblemDecision
Team members “report” to the RP, not to the team
  • Make sure everyone understands why you need scrum (share information within the team);
  • Scrum master can avoid visual contact with the speaker (hide his eyes or stand behind).
Lateness
  • Introduce small (symbolic) late fees:
  • Move scrum to another time:
Discussions are dragging on
  • Hold meetings while standing;
  • Each person to allocate for his story no more than two minutes. After this time, pass the word to the next;
  • On the next screen it is useful to make sure that all the " Item list " have been worked out;
  • Collect " Item list ". As soon as a serious discussion on a technical topic comes up, the RP writes " Item list " in the What / Who / When format:
whatWhoWhen
Discuss the problem with drawing controlPeter and VasyaImmediately after scram
People get distracted during a scram
  • Again, the meeting should be short;
  • It can be decided that during the meeting everyone should stand;
  • Go to the meeting room away from mail and other temptations;
  • The RP manages the meeting correctly - it does not allow outsiders to flare up.
The problem of the language barrier - not everyone understands English wellIn this case, you can use the so-called. Scrum Notes. Each team member (including the onsite team) before the scrum sends an answer to three questions in written form to the master, who consolidates them and sends them to the whole team. This does not negate the scrum itself, but makes it easier for everyone.

How to make everyone follow the rules? First of all, they should not be mounted on top. Decisions on the application of certain rules should be made by the team, not by the RP and not by the customer. It can be useful to make the rules visible, for example, to write them on a flipchart or on a blackboard. Feel free to change the rules if they are outdated.

About the development of scram
Scrum is an extremely useful practice. Over time, team members learn to properly conduct scraps and participate in scars. Problems with conducting becomes less (provided that you solve these problems!). After a while, scrum turns into a routine event, and you may want to make it less formal and more fun. Some tips from Jean Tabaka from the book Collaboration Explained:
You might think that this is nonsense and so you will not succeed. We'll see what you say by scruming with the same people for several years.

Source: https://habr.com/ru/post/21751/


All Articles