How to plan a project. Managing changes in a web project

Introduction

If you are planning to develop your web project, and you need tips and ideas on how to organize this process, then read this article.

We will talk about planning the possibilities of a future product, wrong steps, misconceptions that you may miss when working on your web project. This can be attributed to any IT project: creating a website, webapp, program, etc.

The accurate nearest version of the product and general plans of the product

Often the customer wants to thoroughly describe a huge product in the very first technical specification, i.e. to take into account all the requirements that may be required in the project in the future.

This is a bad approach for most projects for the following reasons:

  • everything will change very quickly. Many changes will appear during the work on the project. This is especially true for startups, where there is no clear understanding of what will eventually produce results.
  • it's a long time. The first version will contain a large volume, which requires a lot of time to implement.
  • delay of feedback from the consumer. If the product is made immediately with a full volume, then we delay receiving feedback from the user. I.e., in fact, the product is made in a vacuum without real use.
  • extra expenses. It may happen that some of the implemented features of the program are not needed by the consumer, or they are needed in a different form - this is additional costs for rework.

Alternative approach:

  • determine the nearest version of the product, which will contain the main features that are currently relevant. The smaller the version, the better.
  • write a detailed task for this version
  • write out a plan for the development of the product in general terms, so that all participants have an idea about the future vector. But at the same time, a lot of detail is not required here. It is simply not needed here - everything can change by the time it is implemented, and there is no point in describing it now.

This approach reduces the risks of the product (doing something wrong, overspending the project), reduces the cost of implementing version 1, accelerates the receipt of feedback on the product.

Consider your scale

There are situations when a client wants to make a giant project without having enough resources, competencies and experience. This usually does not end well.

It is necessary to calculate your possibilities well.

The project is not a sprint, but a marathon.

If you expect to shoot at a short distance, then probably nothing will come out. The project should have a sufficient margin of safety in finance, in terms of competencies in various areas.

A good metaphor is trying to cross the sea on an ordinary boat. This is potentially possible, but in practice it is accompanied by large risks and small chances of success.

What does this mean in practice?

Moderate your appetite. Make the product smaller in volume. Do not play "big uncles", where the project may not pay for itself for years and live at the expense of external subsidies.

Your project should create a financial trickle as soon as possible, even if it is small, but stable. This will allow you to experiment indefinitely with the possibilities of the project for future growth.

In a project with an unclear result, there is no fixed budget and deadlines

This idea is difficult to accept for the product owner. I want to know the exact amount of my expenses. This is an understandable desire, dictated by the fear of going over budget with the possible risk of closing the project.

In reality, no one can say exactly the size of the budget for the entire IT project. This is primarily due to the variability of requirements. No one knows what's waiting for us around the corner. Maybe we will need to implement a large API in the project for integration with some system, or maybe make a mobile application. Maybe they will issue a law prohibiting advertising in the search engines of our site, maybe our lead programmer will go to another place, maybe something else. All this affects the budget and timing of the project.

Of course, in any case, you need to have some initial estimates, but you need to treat them exactly as estimates, not facts.

And the most important thing is to be ready for changes in the project.

The best cure for this uncertainty in the overall budget and deadlines is to move in small steps, analyze feedback, constantly check with the compass (whether we are going there, how much the discrepancy with the initial budget is).

A metaphor is the light of headlights in the dark. You can't light up the entire road, but you can make the section of road in front of you illuminated at a given time.

Transmitting information through documents, not in words

There is a type of customers who like to tell on the phone what kind of system they need to make. This is an extremely inefficient method. First, it should be repeated to each contractor. Secondly, it is very difficult to perceive such information by ear. Thirdly, it simply requires more time and it is difficult to transfer it to another person for study.

It is better to form all activity through documents. It is much easier to form a document by removing everything unnecessary from it, and adding all the specific elements.

And then just give it to all interested parties for discussion.

Tools like Google Disk allow you to work together on a document, comment on it. This makes the study deeper and more useful than discussing common points on the phone on your fingers.

If you take me personally, then the manner of the customer to explain everything on the phone with an unwillingness to formulate something on paper for me is a marker that either a person is just working off his time (if he is a hired performer who fills the time with these conversations), or a complex client with whom in the future you need to constantly sit in calls to discuss each task.

Vary the parameters budget, volume, deadlines

The project has 3 components that are tied to each other: the amount of work, deadlines, budget. If you change one thing, then other parameters change as well.

  • We want more possibilities in the project - the budget and deadlines will grow.
  • We want to speed up - we can increase the budget for speed bonuses.
  • We want to reduce costs - we can throw something out of the planned version.

There is a fourth parameter - quality. My opinion is that you need to do quality according to the standard standards of your company, i.e. try to do it as efficiently as possible for your situation.

Of course, it may be tempting to speed up the project or reduce costs at the expense of quality, but in the end this turns into future problems. In fact, you simply transfer these costs to the future, and with interest.

It is much better to speed up the project, reduce the budget by properly reducing the amount of work. Many elements in the project can be made easier (but at the same level of quality), some points can not be done at all in the project.

The most important thing is to remember that you can change the budget, you can speed up the project. The project is a variable, not a block-monolith.

Lay down resources for alterations, leave some place for maneuver

You can't plan exactly in a project. There is uncertainty in any project, and this uncertainty will require costs.

We always need a certain margin of safety to close these uncertainties.

In addition to the uncertainty in the requirements for the product, there are force majeure.

In fact, a startup is a big force majeure in itself. You need to be ready for anything. Work out the possible risks and evaluate the possible additional expenses in the event of the implementation of these risks.

More than once I have seen such a situation when the entire budget in the project is spent on the main version, a large amount is made, but there is no budget for new changes anymore. A large initial volume is the main reason for these problems. It is necessary to reduce the first version, not to burn the entire budget for it, leaving funds for future revisions/improvements/improvements.

An additional possible expense may be various product optimization - in terms of speed, usability, and polishing of individual features.

All these are necessary things. The question may arise "why didn't the developers take all this into account at once?". It is impossible to take into account all the nuances at an early stage. A lot depends on the specific experience. Some elements are taken into account, some are not. In any case, the project should lay a certain reserve for grinding, which may be required already during operation.

So how to keep track of the platform's possibilities.

For these purposes, you can use a backlog. In fact, it is just an Excel table with the following fields: Requirements, Priority, Complexity, Status, Stage.

A backlog is not a technical task. This is a great place where you can think about future wishes for the system, assign priorities, and detail them.

It is not necessary to carry every new wish that came to mind immediately to the developers. Put it in the backlog, think about the details, whether it is exactly needed in the product, how it combines with other features of the product, whether it meets the vision of the product.

With such processing, a lot of features simply fall off - they are not needed in the product. As a result, you save the budget, valuable developer time, and the product retains its focus.

Management of the general product backlog is the prerogative of the product owner. It is he who should thoughtfully, with an understanding of the details, determine the composition and direction of the product development.

Combat reconnaissance

There are such opportunities in the product that are difficult to immediately identify, detail, understand how to approach them.

You do not need to try to immediately implement them into the product. They need to be examined, felt on the stand in their raw form. Understand what kind of animal it is. And it is possible to abandon them.

Put in the next stage not the full implementation of a new feature, but the creation of a simplified prototype, a demo stand with the specified simplest features.

The task here is not to add another feature to the product, but to understand how it works, how it suits the product, whether there are pitfalls and how best to adapt it to the product.

In a number of projects, we have heard the phrase "We pay only for the implemented features of the product". This approach has a right to exist. But this reduces the product's possibilities, makes its management less flexible, the developer will simply re-invest in working out such possibilities (if this is the same new element for him as for the product owner).

Also, the developer will offer only what is familiar to him, while bypassing potentially important implementations in the project that require additional initial study. Thus, the customer shoots himself in the foot - he restricts the possible development of the product, and makes it clear to developers that research on improving the capabilities of the product is not welcome in the project.

Cooperation, not confrontation with contractors

Some customers perceive working with a contractor as a battleground, where it is necessary to squeeze out a discount as much as possible, quarrel with the quality, touch the manager to the quick, raise panic at any error in the product.

Whether the customer has the right to do so. Of course it does, he also pays in the project. He needs a result, and he achieves it through these methods.

But think about the other side of this question.

There will be no trust between the parties on the project. For any sneeze, you need to make a piece of paper and do it strictly according to the technical specifications. Developers will not offer ideas, because they do not care about the project of such a customer, who tries to squeeze them for every reason.

At the first convenient opportunity, developers will leave the project. Such a rotation on the project will not end well for the project, plus it increases the costs and risks of making mistakes.

The developer will compensate for any cost of the client by evaluating the work. Executors will save on internal quality. And now decide for yourself whether these antics of the customer are worth it in order to get the full range of project "diseases".

From personal experience, we try not to participate in projects with warrior customers. If the product owner shows his claws at the project development stage, we simply do not participate in such a project. This is economically more profitable than getting stuck with a complex client and constant butting about and without.

How to build cooperation with contractors:

  • work strictly according to the technical specifications. The stricter the approach, the fewer reasons for misunderstandings and conflicts
  • respect the interests of your partners. Do not try to bend the partner. The partner is not a fool, he sees and understands all this. And if the partner is a fool, then at the time to think about your business environment.
  • fulfill your obligations as accurately and promptly as possible. The more predictable the partner is (without tricks), the easier it is to work with such people.
  • respect, politeness, benevolence. Goodwill (real, sincere, and not made of oilcloth) is an easy way to smooth out the acute, controversial issues that occur in any project.

Conclusion

We have considered some aspects of project management in terms of general planning of project tasks.

If you are just starting a project, start with the project concept document (Project Concept Template). Formulate a detailed vision of your product for yourself. First of all, the concept is made for yourself, and not for the service provider.

If we talk briefly about project planning:

  • define the product vision;
  • write a general outline plan for the product movement;
  • determine the minimum first version of the product;
  • launch, polish, iteratively develop the product.

The author of the article is Ruslan Ryanov

The creator of the Falcon Space platform

Watch demo

Product marketplace Service platform Rental site CRM for B2B CRM for cargo transportation
Demo solutions can be developed and cardinally business logic for your subject area
 Demo of ready-made solutions

How do I know the budget / timeline for my project?

1. Create a project concept

Concept Template

2. Send us your concept paper

to Whatsapp +7 920 954 2217

3. We will prepare a commercial proposal with details by modules

KP example

Falcon Space Platform

This is a reduction in the cost of ownership

at the expense of fewer people to support

This is a quick change

while using the program

This is a modern interface

full adaptation for mobile devices

Component demo stand
At the stand you can see various components in action - tables, forms, modal windows, diagrams, a map, etc.
Solution demo site
Basic solutions that can be flexibly adapted for yourself - change the appearance, business logic and even the structure of the database.
Discuss the project
Ask the initial questions about the project that concern you right now. We will advise you for free and recommend the best solution.

If you like our articles, then please subscribe to our channel in Telegram - Falcon Space.
In it we will publish updates on articles and other materials regarding our platform.