Get best of the week

How to understand that a project is a project and run it correctly

Two days before the demo. The team saws specific functionality - the integration of our product with Google Maps. Integration is sawn "on the knee" - the main thing is to have time to show the potential client the capabilities of the system.

The demo passes and the client pauses to think.

Six months later, sellers sell another solution with Google Maps integration to another customer. Well, they saw that half a year ago everything worked on the demo.

What is the problem here?

I worked in different companies. Somewhere it was clear that we were going to do this project. Why was this clear? The client came and said, I need to make just such a system and describes it. The manager plans how much the project will take in time and money, negotiates with the client and work ahead. It is - the charter, project plan, risks, quality control and other project artifacts. Clear and understandable.

In other organizations, the project was launched from above - we are doing this and this, take people and go. Less expanses, but also clearly and clearly.

Thirdly, the most difficult, with projects it is not easy. In my opinion, there are a number of problems about which it is difficult for me to judge from my level. Everything happened as described at the beginning - the project is more likely dead than alive.

What problems come up?

  • , — . , .
  • .
  • , .

The project team began to work out the implementation plan and “suddenly” nuances appeared.

A classic of the genre, however - both we and the client understood differently “integration”, for example, or the term “audit”. For them, it was a terrible word associated with evil verifiers, and for us, a term that means functionality.

As a result, the implementation process translates into a revision project. Formally, the draft charter did not change; all high-level goals remained the same.

How to taxi? The main task is to find out exactly what needs to be done, determine priorities, timelines, resources, risks, notify all interested parties, prepare several development scenarios. As a result - to agree with the client on the required amount that will fit into the affordable budget.

The main nuances - the project has already been sold, it already has a budget and the amount of work. Pretty tough restrictions. But this does not mean that you need to swallow it all and take it for the truth in the first instance. In 99% of cases, you can negotiate, whether it be a client or a sponsor.

We start the project


It so happened that I am more a supporter of clear plans. Waterfall and the PMI approach are similar in spirit, although some aspects of Agile are not alien.

So, the project begins and the proof that the project is launched is the charter of the project. For those who are little familiar or unfamiliar, I will explain what kind of beast it is.

According to the ideology of PMI, this is a document that describes the top-level goals, timelines, budget, risks, and also gives formal authority to the project manager and, importantly, determines the name of the project. Below I will explain why.

Often, the charter is prepared by the project manager, agreed with the sponsor, customer and other key stakeholders.

In one of the firms where I worked, there was no clear definition of what a project was. There was a certain activity, a certain flow, which was called a project, but in fact it was not. That was an assumption. Okay, let's call it a project and at least decide on a name so that everyone understands what we're talking about. There was confusion with the names, when the sponsor said - “What is the progress on the project of integration of solutions?”, Then the head of the department and the manager thought about different things. The head of the department called this project “customer integration”, and the project manager “database optimization”. Everyone thought at his own level.

Agile has no budget and deadlines, even top-level ones, as everything is flexible and can change at any time. Yes, Agile can estimate the completion time, but only after several iterations when the team’s performance is evaluated. But there are goals. We know what we want to do.

I will give an example. There are two development teams. Both have the same project - to develop a mobile solution for food quality control.

Team A works on Waterfall. Team B works on Agile. Different approaches to planning and development. But the goal is one. So why not fix it at the start? What is the likelihood that team B in the middle of the sprint will understand that the client does not need an application for quality control, but needs an application for recording football matches? Very small, with a greater probability they will nevertheless come to their original goal.

NB: I'm making an assumption and talking about custom development, not about startups.

With the name, timing, budget, more or less clear. What about the risks?

PMI refers to this formally. In my opinion, the risk management process is an independent thing. Let me explain what I mean.

The risk management process consists of the following stages:

  1. Identification
  2. Analysis
  3. Planning
  4. Monitoring

This is essentially an iterative process. It is applicable to both operations and Agile approaches.

When starting a project, there is one global risk - it may fail.
Edward Yordon’s book, The Kamikaze Path, has an interesting thought - it’s worth treating any project as a failure. With this attitude, you need to build a development strategy, that is, think through a set of actions that will make a successful project a failure.

So why not push off from this thought and make it happen? Yes, there is little data at the start. But that’s why they are high-level risks, in order to show interested parties what could go wrong.
Total - the draft charter is a document that allows all key parties to agree on one terminology, global goals, and high-level risks. Everyone understands where we are going, what we want to achieve and what could happen wrong.

Project goal setting


Many novice project managers went through this - you need to draw up a charter and determine the purpose (s) of the project. And such monsters are born:

  • Development and implementation of a corporate program and project management system to improve interaction between departments;
  • Recycling the tax accounting system to optimize the accounting process;
  • Implementation of a cost control system to increase the profit of departments.
  • Such projects cannot be completed. If you see this wording in the charter, then this project is already dead.

Why should a “corporate system” improve collaboration? How will the customer understand that she did this?

“Recycling the accounting system” - we will rework it, but how? Change the menu items in the interface. Does this streamline the accounting process?

“Implementation of the control system” - how do we understand that the system is implemented? Suppose everyone agrees that it is implemented, but will it increase the profit of departments? What if we do not implement anything, but the profit increases, for reasons beyond our control? Can we assume that the project has reached its goal?

If we formulate the goals of the project, then this should be a set of goals: what needs to be done specifically and how do we understand that we did it? What should we see, feel? What should change? What costs should this be achieved? When? If there are several goals, then what are their priorities. It may turn out that the goals depend on each other, or it may turn out that some goals are mutually exclusive.

Setting SMART goals


  • Specific - specific.
    What do we want to do? Something to improve? And how much?
  • Measurable - measurable.
    Can we measure the goal in money, percent, time saved?
  • Achievable - achievable. Do we have enough resources, knowledge, experience, time to achieve the goal?
  • Relevant - relevant or significant.
    Here you need to determine what is required to achieve the goal?
  • Time bound - time limited.
    How long should the goal be achieved?

Example: Implement a project management system based on Project Server for 20 workplaces of the project office using an electronic risk register and emails with the function of automatic notification of postponement of deadlines.

The system should help reduce the timetables of each project by 15% within 2 months after launch.

The system should be implemented in 6 months, not later than December 15.

Already closer, but still possible to refine.

Additional questions you can ask:

  • What should be done?
  • Why do you need to do this?
  • What benefits should the project bring?
  • Is everyone familiar with this plan?
  • Does everyone understand him the same way?
  • Does everyone agree with him?
  • When do you need to finish the job?
  • Who is the end user?
  • What quality do you expect to receive?
  • What functionality is expected?
  • What facilities are available?
  • Who controls success and by what criteria?
  • What should not happen in any case?
  • What work does not belong to the project?

The last two questions are the so-called “not goals”.

They describe what is not relevant to the project and what should not happen, as this interferes with the progress of the project or violates internal restrictions. Results that are not relevant to the project should not be characterized as harmful, but you should be aware that the customer does not pay for them.

Summary


You see, there is a certain amount of work with certain outlines and there is even a timeline and budget for it? With a high degree of probability this is a project. We are negotiating with sales people so that both managers and engineers are involved in the sales process. At least as consultants - and then they will work with it.

Before starting, we determine the name of the project and terminology. We write the charter and form clear and understandable goals. SMART is our everything.

More articles:


All Articles