Features and risks of a large web project. How to build work between client and developer

This article was written after a series of reports at the seminars of our company , which showed that the topic is extremely interesting to many professionals and customers. We hope you enjoy it. We welcome comments. The co-author of the article is Alexey Shkarupa, project manager of Domino .

How to define a big project?

What is a big project? How is it different? What is dangerous and what is interesting?
The truth is that for each client and developer a large project is a concept with different content.
A large project is a unique order that creates new risks for both parties.
New risks means you have no proven technology to work with such risks. What is a big project?

We have formulated a number of signs:

• The launch is carried out in several stages .
  Phased commissioning always entails greater risks than starting at 1 reception. At the same time, experts indicate that the maximum duration of one stage is 3-6 months. At longer stages, changes accumulate, the negative is on the part of the waiting customer, priorities change, everyone gets tired and the launch becomes more and more problematic.
  ')
  
• project exceeds the previous one more than twice .
  This criterion applies to both the client and the developer. If a client has previously ordered only business cards, the order of a large online store and communication with the developer will be full of surprises for him. Similarly, with the developer, it is almost impossible to make a project more than double your past experience without serious mistakes.
  
  
• The project is based on a new, non-rolled idea or technology .
  An untested idea or technology with high hopes is always a risk. The simple rule is: a new technology always reduces performance for the first time. A new idea, even worse, calls into question the whole undertaking.

Features of a large project

Project management is a reduction in the likelihood of risk occurrence. In a big project there are special risks:

• A large project is always a policy
  A large website, web project, automation always changes the logic of the business. It is always a revolution.
  So, there will be people who will suffer from the introduction, who are NOT interested in launching the project.
  There are always several project participants on the client’s side, and parasitic power, their efforts to fight each other, always create additional problems.
  
  
• Uncertainty of requirements and scatter of estimates
  In this block we will talk about the risks of the client.
  A big project is big because there are a lot of unresolved issues.
  At the initial stage, the task is usually described only in general terms, which is completely understandable and normal.
  On the other hand, when deciding whether to start a project and select a contractor, the manager always wants to know the exact time and cost of the project.
  And there is no such assessment. What to do?
  The practice of collecting proposals from different artists is common.
  The accuracy of this review is always extremely low, even if there is a common TK.
  As a result, the manager is in a situation where he does not have the opportunity to choose reasonably. The prices differ tens and hundreds of times, the companies performing under the superficial examination are all the same.
  
  
• Integration with external information systems and integration into client’s business processes is a special and big risk.
  Large web projects do not exist in a vacuum, they exchange data with other information systems. Such exchanges, as a rule, require the completion of at least one of the systems, often both. Organizationally and technically, this issue lies on the boundary of authority and responsibility of the parties to the project, and therefore its solution is often delayed.
  The situation is similar with the training of the customer’s employees and the start of actual operation. The unanimous desire to work in the new system is rare, and the implementation process is a separate big question.
  As an acquaintance of the introduction of accounting systems once said: “in order to program it, one needs money, and in order for it to work, others are needed”.

In the Domino project, the site was of great strategic importance to business, and the level of interest of management was very high. In fact, this is a big plus. Initial TK surveyed 50 teams of web developers estimated from 30 thousand rubles to 2 million. Such a spread predictably did not give a decision with whom to do it. The risk of integration with external systems was fully realized - the import files for the site, directories, ad parser were ready 4 months later, and this postponed the launch and required to change the order of implementation in manual control mode.

Customer issues

Generally speaking, the client and the developer are almost equal sides of the development process, and they have similar risks. What questions does the client pose (or should put) before himself, who has decided to do something unusual and large - a large web project:

• purpose and task
  You need to understand why a project is being created. Profit? Glory? Main business support? New market?
  How will the result be checked?
  What is the timeline? it is clear that "yesterday", but really what?
  These questions should be given thoughtful and most reliable answers.
  Marketing appeals instead of project goals and objectives are a bad sign.
  
  
• framework and priorities
  Often they think like this: since our project is large and unusual, let it do everything at once. It is very important to understand and fix the scope, limits of the project. Remember: the chances of a successful launch are reduced with each extra day. It is better to run fewer functions, but faster and better.
  Priorities allow both the customer and the developer to understand what is most important in the project, where to start, and what is secondary and can be done later with less attention.
  A competent project manager always tries to do the hard part first, and not the simplest. And having done it, it tries to launch it into work on real clients and employees.
  
  
• customer load
  Often the client does not realize how much he will have to work. When creating a large custom project, the load on the client’s specialists can be very significant. In our practice several times there were cases when projects collapsed or their deadlines and composition changed greatly because the client manager was not ready, could not or did not want to devote a lot of time to the project and competently perform his part of the work - to think, prepare information, make decisions , analyze options.
  Often, on the client side, you need not only a manager and an operator to enter data, but also developers, system administrators, marketers, and copywriters.
  A misunderstanding of segregation of duties (“how did I think that you do it too !?”) is a big risk.
  A smart and far-sighted client, regardless of whether he or she is trusted by the employees of the contractor, will surely ask: “what and when should we do?”. Careful - also write it in the contract.
  In the Domino project we were lucky, and twice. Initially, Olga Semirogova (Vorobyova) was involved in the project, which plays an enormous role in the design of the site. Unfortunately, in the midst of the project, she left the company, and we started the project with Alexey Markelov, who showed both knowledge, experience, and common sense. Everything worked out, although a change of contactee in a project is one of the hardest risks.
  
  
• who will do and how?
  Which developer to choose? External people or your employees? Local or "Varygs"? Box system, flexible framework or original code, where is “all yours”?
  A complete analysis of this issue does not fit into a dozen of such articles, I will say briefly the main thing.
  
  Your team is good if you have one: worked, professional, structured and managed.
  A team cannot consist of one person. Attempting to assemble a team "from the street" and immediately instruct it to develop multiplies the risks.
  Territorial proximity to the developer, the opportunity to personally meet and talk, and if necessary, work in the same room greatly simplifies the dialogue, especially at the stage of setting tasks and passing the stages, and then the entire project. Sometimes the customer is often willing to pay several times more precisely for this opportunity.
  One of the main principles of effective software development is that personal communication is the best way to communicate.
  
  
• How to be sure that everything will work out?
  custom development of a large project is always a very risky event. A survey of IT directors by Intelligent Enterprise magazine showed that
  
  31% of projects fail
  53% of projects are completed with a budget overrun by an average of 1.9 times
  16% (of all!) Projects are put on time and on budget.
  
  Agree, would you like to get into 16%? However, there are much more chances, especially in the absence of experience, caution and good luck, to get into other groups.

Developer Questions

Generally speaking, the relationship between the developer and the client, especially with the first joint work, the tense situation and sins on both sides, and even a slight feeling of mistrust, can easily slip into the plot of "someone else against a predator." It is unpleasant humanly and hurts the project. In addition to thinking about the quality of the project, the developer should take care of the relationship. However, as the client. So, what an experienced developer should do:

• recognize a big project
  In time to understand that the project is new, large, risky and see its risks, and then understand how to manage them.
• evaluate the project
  in any way he owns, try to estimate the amount of labor costs, and then reasonably apply the “factors”: a new technology, weak TK, tight deadlines, lack of a well-coordinated team, poorly designed restrictions.
  Generally speaking, there are statistically proven methods for assessing the scale of the project PERT, CoCoMo II and others. In their pure form, they are unlikely to work, but there are useful thoughts in them.
  
• decide on a project management methodology
  Modern, so-called “flexible” project management technologies are often popular among developers. They have many advantages, but there are also difficulties associated with them. It is very important to understand how you will work and agree on this with the client.
• make a list of risks
  And decide what to do with each: accept, transfer, insure, reduce. The main thing is to see.
• do everything for success
  a normal ambitious developer will want to achieve a result. The question is - can it.
  

Main risks

There are common risks of a large project that are always there. There are also specific to web technologies. Here are the most significant:

• incorrect assessment of the task by the executor and too much trust from the client.
  It’s not even bad that the performer errs in evaluating the task and his strength. The bad thing is that he does not understand that his estimates are very poorly substantiated.
• risks associated with the terms of reference and other project descriptions
  There are two main problems:
  - the client may not understand the language of the technical task and even refuse to work on it at all. Like, I already told you everything, you heard me, now do it.
  - for a large project, a technical task of tens and hundreds of sheets is obtained, with a multitude of diagrams and tables. Even with extremely competent, organized and motivated employees on both sides, such a document will contain mistakes, inaccuracies and contradictions. It will be incomplete and irrelevant in some places, especially towards the end of the project. The leadership will change priorities and new ideas will appear.
  Practice shows that even after several months of reading the TK, you can find in it a couple of amazing paragraphs that significantly change the already formed understanding.
  Purely theoretically, it is possible to write an exhaustive, consistent and detailed TK for the project, but this will take a lot of time, during which the TK text will become obsolete, the project itself will not be so relevant.
  
  
• big terms and loss of contact
  If the development is carried out in large stages, what is the logical result of an attempt to do “everything at once on a large TZ”, human contact between the parties is lost in the process, many details are forgotten, the customer gets tired of waiting and experiences more negative than anticipating success. This risk lies not so much in the rational sphere as in the emotional one, and therefore it is more dangerous.
  Its consequences are difficulties in accepting, an uncontrollable stream of wishes, which the customer considers to be errors or logical requirements, and the performer - pure "wishes".
  This risk ultimately threatens not only the project, but also relations between the parties.
  This risk was partially realized in our Domino project. We have been doing it for more than a year, and during that time a lot has changed. In our opinion, it was better to start first one of the most difficult sections (for example, Auto), run around the general mechanism and then develop. The customer chose to find out the price and time for “all at once”, although much was not ready for such a large stage. As a result, a lot of time, nerves and money were lost.
  
  
• changing requirements and development cost
  Changes in the project is completely normal for the client, for business, for life. There is nothing reinforced in real life. No matter what project management methodology you choose, there will be changes.
  Perhaps the contract or practice of their relationship can be minimized or even crush at all, but it is unnatural. And each next day of the project before the launch will only save these changes.
  For a developer, working in the conditions of a changing task is similar to the race of Achilles for a turtle: close, but you cannot catch up.
  There are several ways to work with such a risk, the choice between them depends on the project and on the client’s relationship with the developer.
  The general recommendation is that the stages are smaller, the launch is faster.
  If you work badly with this risk, there can be 2 consequences at once:
  - the project is always ready by 90%,
  - the price of development (in time, money, nerves becomes unacceptably high: the quality suffers, short-term decisions are made, there is no testing).
  
  
• real data volume and performance
  A separate big task, which is often forgotten or superficially done, is to test a project completely on a real volume of data, users, views; find and eliminate all bottlenecks in the project.
  Such load testing is not very technologically difficult, but extremely useful for the future.

Key decision issue

When creating a project, the most important thing is the people who will be responsible for it. No technology can replace brains and the desire to solve project issues. What kind of people should it be? They have to:

• have experience in such tasks (project size criteria)
• will understand the idea and “catch fire” to her, want to engage in the project
• ask you questions that you didn’t ask yourself
• will be nice to you. You will communicate a lot with these people, and if there is no emotional contact, problems cannot be avoided.

Perhaps such a developer seems to you a superman, an ideal contractor who is not in nature? Maybe so. But generally speaking, there are many decent web development teams, and there is a choice.
You just need to do it, and done consciously.

Interaction technology: ideal and reality

In theory, everything is simple.

• The customer does not want any "straining". He wants to set a task, and not a technical language, but the language of business.
• He wants that the development was carried out quickly and without errors, and the result met all the requirements, including not explicitly stated.
• The customer prefers telepathy to all types of communication and is inclined to blame the Contractor for all errors of understanding.

In his logic, that's right. The artist is completely different.

• He is waiting for the customer to clearly set the task and be able to quickly answer specific questions.
• Developers will offer their options, but expect that the smart decisions will be made by the responsible and contactee from the client.
• The performer prefers the paper detailed consistent task to all types of communication, preferably written for him or even by the performer himself.
• The solution to all problems of mutual understanding such a developer sees only through the search for the corresponding item in the TK.

In his logic, that's right. There is a contradiction in priorities and prerequisites for conflict.
In practice, everything is different.

• The customer is rarely ready to give the information that is objectively needed for the project. Not only the technical side of the requirements, but also the understanding of the business result is changing. Often, during the project, the key employees of the customer change at the most unpredictable and uncomfortable moment.
• The executor (under pressure from the customer or from his own inexperience) rarely has a reserve in time and money for the realization of risks. If in small projects such a strategy is still viable, then in large ones, when there are many risks and some of them are accurately implemented, this is extremely dangerous.
• The terms and costs mentioned without a stock are difficult to change later, and it’s impossible to meet them if something goes wrong.
• It is almost impossible for the developer to have programmers ready to include them in the project. Most likely, people will be taken from other works, often with the imposition of tasks. All of this makes it extremely difficult to plan resources and increase the requirements for meeting deadlines.
• And deadlines in large projects almost always fail.

Often contradictions lead to conflict.
Almost always in a large project at least part of the risks is realized, and almost always it goes not according to an agreed plan, but in the manual control mode. In our project, Domino realized the full potential of replacing a contactee, integrating with external systems, the risk of long phases and accumulating changes, and partly the risk of a large TK.

Project Evaluation and Planning

I have already mentioned the situation when the same project was completely sane by the developers on the technical task was evaluated at different times and costs, and the spread of estimates was almost 100 times. At first glance, the reason is simple - the developers are greedy idiots not experienced enough and are mistaken. In fact, everything is more complicated. Even with experience and knowledge, the accuracy of the project assessment for TK, especially brief, is extremely low. If there is no paper intelligible document with the described limitations, the cost can be safely taken from the ceiling: you will be mistaken anyway. This is an objective reality that at the beginning of the project no one knows its cost and launch dates. The existing scientifically and statistically based methodologies are extremely weak and in practice are hardly applicable. What can be done so that the project will turn out (customer interest) and bring profit (developer interest), and the deadlines will be within the allotted framework (everyone wants):

• rough estimate with margin and detailed plan
  Indeed, you can make a rough estimate, make a reserve of it 10 times for all risks at once (the stock seems huge, but if the risks were not analyzed, no one knows if it is sufficient), then draw up a detailed plan and, if possible, not give the customer any freedom in revising requirements and deadlines.
• first TZ, then assessment
  You can conclude a separate contract for writing a detailed TK. It costs 10-30% of the price of the development itself. The problem is that the client usually does not like that he pays for the TK, which, in his opinion, only the developer needs. In addition, a large and detailed TK is in itself a separate risk.
• development in small portions
  This approach is becoming increasingly popular. The development is carried out in small portions with a duration of 2 weeks to 3 months, tasks for which are not very large. Each portion is paid, each portion is started and expands possibilities of the project. The technology is good because the customer always has a product that can be used. There are not many risks: loss of contact, large TK, lack of testing. There are also disadvantages: no one knows how many servings are required, what will be the total cost and development time. The client often does not like it.
  However, this is symmetrical: the developer never knows the whole task, which he often does not like.

All technology assessment and planning of a large project has its drawbacks, and your choice should be determined by the essence of the project and the relationship with the customer.

Agreement and rules of the game

The paradox is that most developers apply a standard contract about nothing. Such a contract does not fix deadlines, obligations, the division of responsibility, the form of submission of materials and so on. According to a recent study, 30% of sites are made without a contract at all. If creating business cards is forgivable, but projects for thousands of man-hours cannot be done under a weak contract. So, what should be the contract:

• The contract can be simple, complex, flexible or formal, but it should be written down the truth, the real scheme of work.
• The contract should be written in such a way that if the representative of the client or the manager of the contractor is replaced by other people, the project can still be completed. No substantive parts of the arrangements should remain oral.
• Good things are not done by contract. Good things can only be done in human relationships. The contract is an insurance in case of problems.
  

No need to automate the mess

When designing a site, thinking through the interface, logic and details, a normal analyst, the manager will offer his options. Simplify the logic, change the sequence of steps, revise the rules. These are not only technical or design changes, they will concern the essence of the processes, business logic. "If you automate the mess, you get an automated mess." Not worth it.
Why is this happening? The third-party analyst is a “fresh head”, who sees not entirely logical or not uniform elements of the project and can offer his own. On the one hand, such changes are often extremely useful, as they make the project easier, its launch is faster, and support is cheaper. On the other hand, only a representative of the business, the end customer can accept the change, assessing it from his point of view.
For example, in the Domino group of newspapers, Volgograd and Volga newspapers use significantly different ways of calculating the price of an ad. If they do not lead to uniformity, two different feed interfaces will actually be required, which will confuse people. And if you change the formula, change and financial performance and streamlined scheme of work. A large project is both economics and politics.
The developer should offer, the Customer should not be surprised and consider the proposals seriously, and everyone should think about the quality of the project. It’s a paradox that everybody usually wants success, but they represent him in such a different way and cannot talk to each other so much that the problem of interaction can spoil everything even in the absence of serious factual differences.

Task documentation

Documents are an important part of work organization. I had to deal with projects where the total number of regulations, instructions, specifications reached several dozen. Documents are not a panacea, and there is no universal recipe. What is the specificity of a large project:

• a lot of information
• high complexity
• details are unknown at first, and then goes clarification.

What scheme we used in the Domino project, and it worked well:

• a brief statement of the problem in the contract. 6 sheets of text with restrictions: no more than 30 types of ads, no more than 10 exchange file formats, no more than 300 fields in all data entry forms. These restrictions are very important.
• we did the actual technical task based on Axure, where we created live clickable layouts, several diagrams documenting the change of ad states
• TK text was written, read, discussed in google docs

Although the TK turned out to be very large, it was vividly and collectively discussed in the process of writing and editing.

Tracking the development process

When the task is signed and production is started, some things are simply necessary:

• Gantt chart where you need to mark actual and actual dates
• bugtracker where it has limited access and download
• regular meetings with clients (especially if the project is done in one huge piece)
  

Which would be extremely useful, but unfortunately we have not done so.

• the inevitable changes in the TK, caused by the correction of errors, clarifications (for example, added a basement field to a private house) should be recorded in the list of changes. We were scattered in the mail.
• each stage must be checked tests, preferably automatic. And the tests themselves need to be prepared before implementation.

Delivery of the project. Stress Testing.

When a project is handed over, user testing is always done, sometimes unit-tests of code. We believe that another type of testing is extremely important: load.
I'll tell you on the example of Domino:

• right in the contract, we recorded the requirements for the work of the site on shared hosting: 200 thousand views per day (about 3 views per second), average page generation time to 0.5 s, error rate 50? no more than 1%
• the specifics of the project is that the data is very intensively updated and caching mechanisms do not work very efficiently
• when we passed the project, we conducted a test (Timeweb hosting, Eterno tariff). The average generation time was about 0.2 seconds, there were no 500 errors at all. 200,000 page views survived easily
• It is significant that during the test about 10 bottlenecks were found in the code that required processing. The elimination of these problems gave about a twofold reduction.
• , .

I think that doing a project as a set of stages, each of which is evaluated and launched separately, is the best practice. This is the best option from the point of view of planning, and the quality of the result, and for business. For the client, usually all the arguments are outweighed by the only plus option “one contract, one TK, one stage” - the launch date and budget are immediately fixed. The sadness is that the deadline cannot be sustained for obvious reasons (tightening approvals, realizing risks, processing requests), and the customer suffers. Accordingly, the project due to the stretching of time turns out to be much less profitable than planned, and the developer suffers. The paradox is that the risks in the phased work are less, and the chances of getting a qualitative result are higher, despite the open budget and the project end date. Separately, it is necessary to say about this “end date”.A modern project created for business is constantly changing. And there is simply no final date. There is a current state of continuous change.

findings

A large project is not as scary as it may seem. Everything can be solved if the customer and the developer have common sense, experience and desire to solve problems. We believe that:

• work in stages is the best option;
• data exchange with external systems must be done and tested at the very beginning of the project;
• it is necessary to work on an assignment collectively and “live” via Google Docs;
• a big project is always a policy, and it always substantially changes the business;
• and remember: your next project should not exceed the previous one more than 2 times.

And more conclusion

The customer must understand that he has a lot to do in the project. It will be necessary to select an employee who will have the knowledge, competence and the right to make decisions on the project. This employee will have to devote a lot of time to the project, perhaps the whole working day.
And everything will turn out.
The new site Domino (may lie, at Timeweb problems) The
original source of the article, decorated a little neater . Sorry, to fight with the habr parser is hard.