About Development Management Importance

Some reasons project and development management are so vital when developing products.
Possible results of neglecting the managerial aspects of the project.
Many companies and projects have been established around technological ideas. The founders had an idea for an innovative product for which they believe is a significant market. They usually have the required technical knowledge and some background knowledge in marketing.

However, in many of these young companies / projects, the project management and development management areas are neglected. This results either from a lack of awareness or because they believe they "do not have enough time for it". Many companies have a great vision of their product´s future, but no real plan of how to bring it to the marketplace. Their knowledge in coding and hardware design is certainly not enough.

In many cases, the vice president of research and development actually serves as the chief programmer or chief engineer. He invests a lot of time and effort in the technical aspects of the development, while neglecting the managerial aspects. This means that even if he does have the required knowledge and experience in development management, he does not invest enough effort in them. This choice is sometimes made in order to save time, because company management feels that in order to speed up the product development, the R&D manager should also be a part of the "work force".

To hide the fact that the development is actually conducted with only a partial plan, the popular "solution" is to make the development teams work long hours in a stressed environment. This is the way they build the illusion that the maximal speed was utilized.

Working this way causes a variety of problems, such as:

• A lack of time management:

In most cases, there is no internal time management for each day. Sometimes, a detailed project schedule does not exist. In some cases, even a timetable for the next few weeks does not exist. A general work plan is, of course, also missing.

This results in inefficient time management. In other words, since we do not have enough time to build a schedule, we work hard on time-inefficient development.

• The focus is missing:

This means that there is no unanimous understanding of the product and its associated issues.

A common example: not all employees have the same understanding of the company´s targets in developing this product (apart from the financial profit...), market demands, or its financial limitations.

Every developer understands the product definition a bit differently or has slightly different opinions about it. Because of the short time in hand, at many stages during the development process, a developer has to make some decisions on her/his own. In the event of a lack of focus, there is a higher possibility that these decisions will contradict other decisions made by her/his peers.

Example: contradicting development resulting from a difference in product perception. A programmer produces a user interface for the system, while a peer programmer produces the system functionality in a way that is not appropriate for the user interface. Such a situation can result from different interpretations of the general product description.

In this way, the project is dragged in different directions, slowing its progress.

• A lack of visibility:

Meaning: it is hard for the people involved in the project to know what each one has decided or done.

Developing a hi-tech product involves gathering a huge amount of information from various places. It is not possible for the development manager to work closely enough with every developer and to be able to be familiar with every detail. The CEO has even less information about the development processes. At the same time, however, the CEO does have a lot of information, most of which she/he does not mind revealing to other employees, but she/he does not have the left tools for publishing this information.

This means that because managers do not have a consistent method of tracking the product development, they are isolated from parts of the development sub-organization, while the developers are isolated from company decisions. The developers are also not updated regarding new visions of the marketing group so they are not aware that the parts of the product they currently work on, may be already irrelevant, etc.

• The priorities are not well defined:

In most development areas there is not enough time to develop all the existing ideas within the restricted time limits given. This is why the company has to identify what is more important or urgent. Next, the company has to decide which ideas to drop and which ones to defer to a later stage.

With the lack of well-defined and explained priorities, a lot of time is often wasted in solving unimportant problems, while searching for solutions for vital problems may be deferred.

Example: a true story, which is an example of wrong priorities. A programmer spent two weeks in solving a certain problem. According to the development manager´s point of view, that problem was of no importance, as the related functionality was no longer relevant. Since the programmer was not aware of his manager´s priorities, a lot of time was wasted on an irrelevant issue.

• A lack of coordination between the sub-organizations involved in the project (management, marketing, support, operation, subcontractors, development: software, hardware and more).
It can happen (and happens!) even in a company of five people.
As a result, each sub-organization actually invests a lot of effort on a product that is different in definitions, priorities, etc. A sub-organization may not be aware of the problems, preferences and decisions made by others.

This lack of coordination will be fully exposed in later stages of product integration and beta testing. By that time, it may be very expensive to fix.

• A lack of authority / responsibility allocation:

The assumption in some cases is that "everybody is doing everything". The result is that everybody is wasting her/his time on irrelevant issues. Some issues are handled by more than one person, each repeating her/his preceding one, while other issues are not being handled at all - no one thought about them, and each person was sure that someone else was solving the problem or no one had a clue about it, and it was not clear who should be asked (because no one was defined as being responsible for the relevant area).

• A lack of work methods (procedures):

The word "procedures" is associated with heavy documents and filling in lots of forms, but this is not the only way of setting working methods. The goal of a method is to solve a certain problem in advance, i.e., to instruct an employee how a certain task is performed (in that company), in order to prevent him from having to invent a solution himself. A good procedure can help cut out bureaucracy.

Example: we will show a procedure for ordering office supplies in a certain company. If the method for doing this is not defined, every employee would look for her/his own solution, meaning: wasting her/his time on unimportant issues. Therefore, the following procedure can be set:

A paper labeled "office supplies" will be attached to the message board.
Every employee who needs any kind of office supplies will write his name and the list of required items on the paper.
Whenever this page is full, but at least once a week, the secretary will order the items on the list.

No heavy documents. No forms to fill. Instead, a simple method, saving the time of many people. Many procedures can be like this!

• The documentation level does not match the project type and size:

Such a problem can exist both ways: too much documentation will unnecessarily delay the project, while insufficient documentation may delay the project as well. All this is true, starting from the first product version.

It is important to understand what is needed to be documented and how, and also which parts of the documentation should be discarded.

In too many cases, part of the documentation is postponed in order to shorten the development period. It is very rare to find that someone actually came back at a later time and completed the documentation. The lack of documentation increases the dependence of the company on specific developers, because all the relevant information "is in their heads" only. Whenever such a developer leaves the company, it can cause substantial problems.

Example: a true story of a programmer who wrote a sensitive part of an application, but did not document it. For years, whenever changes or corrections had to be done to this part of the product, he was called to help, although he was already working for another company. In some cases, changes had to be delayed until he had the time to perform them.

• Inconsistent maintenance:

Product maintenance, if not conducted in a controlled and consistent manner can, within a short time, draw the product backwards to a point where its architecture is not kept, the documentation is not relevant and many parts of the product depend exclusively on the private knowledge of specific developers. Such a product is hard to change or fix. Any non-trivial update, change or correction requires a lot of time.

We have seen that previous experience proves that development which is not carefully handled leads (if any) to a product of lower quality, less stability and longer maintenance periods. When product maintenance is not carefully handled, the product´s life expectancy shortens.

The inevitable conclusion is that believing "we do not have the time for it" is basically wrong. The truth is "we do not have the time to work without it".

Written by Ronit Sne
IntelliManage