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
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
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 right 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
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
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.
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
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".