The very field of project management is relatively new. However, it already has certifications, standardizations, credentials and other attributes of meaningful scientific and engineering activities. At the time of writing this, the most important certification system in project management is PMP-Certification (Project Manager Professional) offered by the PMI (Project Management Institute).

Many people strive to get this certificate so that no one could question their deep knowledge and professional expertise. The problem is that PMI use PMBOK (Project Manager Body Of Knowledge) as a basis. This book is absolutely praiseworthy if we are talking about running a company with 10,000 to 40,000 employees, where every division of 100-500 people is a tiny square on the huge corporate chessboard. To my mind, however, 98% of the book is applicable to the conditions of staple industry, skyscrapers or Channel tunnels construction, but does not really fit in with IT company management. It is the very management philosophy that is concerned: there are battlefield generals and ones who stay at the base. The former know how to conduct battle, the latter have only read books on it once. I’m not saying that PMBOK is useless. What I’m saying is, a battlefield general who has had battle experience can use the knowledge he acquired at the military academy much more efficiently than if he stuck to what he learned from a book.

I apologize for the long preamble, but when you write an article on project documentation, it’s absolutely essential to refer to certain important books. So, once again: PMBOK is about bridges, skyscrapers and spacecrafts. It’s all about cases where errors in the very beginning of the project result in colossal waste of time and money later. IT systems, by definition, are magnetized areas of data storage media. If there is something you don’t like, just press Shift+Delete and write a new one. In other words, this is a non-material world. That facilitates system engineering process if you learn how to use it correctly. On the other hand, the documentation set, recommended by the well-known Rational as part of Rational Unified Process, allows for creating over 100 documents.

IT professionals are a smart and freedom-loving kind. In addition to that, living in this non-material world, they are not really glued to their workplaces. The market entry threshold is rather low. To build your own website you don’t have to have machines worth billions. A laptop with Internet connection is enough. And so, freedom-loving programming engineers started to break the conventional approach to creating and managing projects, and thus made a shift in the focus from project documentation to the product itself. That’s when Agile methodologies started to appear, hundreds of them, like XP, Lean, Scrum, Kan Ban and others.

Read enthusiastic comments, graduates realize they should use an agile methodology in order to concentrate on the product, on customers and their needs and to improve communication between the team members. And that the useless red tapist – the project manager – should be finally eliminated. Sounds good, doesn’t it?
And now let’s face the truth: everything should match the customer’s needs as well as the project. By ‘everything’ I mean organizing the project management process. Which means that the type of project will dictate the following:

  1. How many iterations the project will consist of, and how changes can be made in the iterations; From the point of view of budget and turnaround time, ideal system is one that has one iteration. It’s like a ballistic missile – you aim it and fire. Whether you hit the target or not will be clear only when the rocket reaches some destination. The more management opportunities the customer gets, the more costly the development process becomes, because overhead costs (maintenance, each new iteration deployment) start to pile up.
  2. How the documentation on the system in development should be presented. Anything can be the source of information about the system, from a beautifully decorated book printed on alligator skin, to some stories told by the customer and taken down on a tissue. The most important thing is that the source of information is not contradictory and available any time to all the people in the project in the latest approved version. At the moment, I cannot think of anything better than Wiki for managing almost any kind of project. Besides, customer’s stories can be written in the project management system right from the start, then implemented, and then, during version deployment – written into Wiki. It may be vice versa – Wiki goes first. Description must, in the first place, allow a new person to enter the project.
  1. Where the source code should be stored, and what restrictions are placed on the code writing. In any case, data backup must be necessarily allowed for, as well as concurrent code editing. Where the systems will be installed, whether the code will be given to the customer right away or it will be stored on our servers – these are questions to be answered. Besides, the customer may have their own preferences concerning the code creation (comments, names of variables, the overall architecture). These problems can also be important and they must be solved.
  2. Which cycle each task, given to the team, is going through, and where you can see who is doing what right now. Essentially, we need to understand how to ensure the team work transparency for the team itself (the leads and the manager), as well as for the customer. Project management systems are used to that end. It can be a whiteboard with sheets of paper or the cutting-edge version of MS Project. It’s important that everyone is comfortable.
  3.  How often meetings and discussions should be held inside the team as well as with the customer. The question is closely connected with the source of information in the project. The more information on the system is included in the documentation, the less discussion is needed during the project.
  4. In what form the team should report on the work done. Some evaluation criteria are necessary. Ideally, all is translated into man-hours, but such options are possible as working on separate modules or versions that were estimated in advance, or (which is the least nice and the most risk-related option) – based on the overall system estimation in the very beginning. Whatever choices are made, reports help all the participants of the project focus on particular tasks and organize the development process.
  5. Who the customer can communicate with and which of the team members can communicate with the customer. Again, communication relies heavily on system documentation. If the customer is tech savvy, any team member can ask questions directly; if not, business analysts are needed to translate the customer’s preferences from their ‘natural’ language into technical requirements for the system.

This might seem frightful, but the rules on how to determine what exactly and when you should do must be simple:

  • No changes are made without previous negotiation.
  • Any change must be preceded by a lot of effort that justifies it, and not just be made because someone felt like it or because ‘all the cool guys do it that way’.
  • Planning is essential to understand what, when and by whom will be done. But they are not carved in stone and so may change.

Author Constantine Makeev