Project management in the organization

Project management is always associated with an effective range of allowable sustainability efforts and available resources to complete the project within the specified deadline. PMI actually refers to three of the above actions, usually referred to as the triple constraint. We would like to discuss actual current relationships and trade-offs between these three elements, namely the scope of the project cost and schedule. We will also consider how can you effectively manage relationships between these elements to consistently deliver projects that meet most of the goals of clients in accordance with a specified schedule and budget.

Why do projects fail?
From my experience if the project fails, it usually almost always means that one or more key elements are not properly managed. Very often the case that the relationship between these variables are in general poorly recognized or unrecognized.
Our experience shows that only 25% of projects end with complete success. Another 25% end in complete failure. In contrast, 50% of the projects end someday, but usually exceed the schedule or budget by 100%. Of course we know that it is not the projects that fail, but the people who run them. What is the conclusion? People usually cannot effectively manage projects.

What are the key variables of the project?
We have already mentioned that every IT project has three major variables. Now I would like to define these variables and show how they relate to each other in different phases of the project life.
The first element is the scope of work which can be defined as tasks to be performed under the project to provide a working product or service. In the IT world it is mostly a product information system. The scope can of course be defined in a number of possible ways. It is usually a list of tasks that define what is called the software development life cycle and which must be implemented in the software project. Some companies define the scope of work through a set of system functions that must be included in the system and processed and delivered to the final consumer. The more features there are, the more complex they become and the greater is the scope of the project. The scope of the project is not the final requirement in relation to the product, but something that is directly related to the delivery of functions and their complexity.

So you can calmly imagine that you are sitting at such a meeting as in the great hall, with the three main knob with scope of names, cost and schedule, and two smaller ones known as qualities and risk. If we take  setting the knob representing the range, we should also take knobs for setting known as costs and schedule, and then get a realistic plan of the project and increase your chances of success. Of course all variables can be set within certain limits, which will also be discussed.

Another element which is important for every IT project is the cost of resources. Resources are allocated and consumed by each project. Resources usually generate costs. The costs of the project are mostly employees and solutions, but these can also be raw materials, purchased software, tools, office supplies, travel expenses and time spent at the computer. The costs are generally calculated in specific money or hours of operation.
Another element is the course schedule. The schedule is something that can be imposed by the client or prepared by us to define the duration of the project. Usually, it is estimated in days, weeks, months or years.

The basic relationship between the scope of work, costs and schedule
With regard to project managers, very often it raises a few questions that allow you to define operating conditions, resources, scope, cost and schedule. Think of your role and of this, that you’re sitting in a large hall and have at your disposal three knobs. I ask my managers several questions very often that allow me to quickly determine the status of the project.
The first question is what we can do with the available task list, doing the least amount of work and in the shortest time, and having very limited resources. The second question usually is, what we can do and how much work there is to do, whether we have a critical deadline and what will be the cost of implementing the critical assumptions. The last question is usually whether  we have a set of features to implement, what our budget is and delivery schedule running the software. Very often it raises also the question of whether it is impossible to design everything on an acceptable level of risk and an acceptable level of quality..
So you can calmly imagine that you are sitting at such a meeting as in the great hall, with the three main knob with scope of names, cost and schedue, and two smaller ones known as qualities and risk. If we take  setting the knob representing the range, we should also take knobs for setting known as costs and schedule, and then get a realistic plan of the project and increase your chances of success. Of course all variables can be set within certain limits, which will also be discussed.
Very often it so happens that at least one of the variables can be constant or permanently limited in order to secure a basis for planning the project. Sometimes it is also possible to limit the two variables if the third variable is unlimited. Sometimes, however, it is that all three variables are limited and then there’s no way you can develop in order to achieve something sensible. And that’s when your problems start. If the project manager cannot manipulate any variable, then he should not even take  a project or simply leave it. If he does not do this, he should consider whether or not to introduce  zero-client software development principles, and therefore “If you do not have to provide a working system, then we can ignore all other requirements and restrictions.”.
The ideal approach is to limit one variable, for example, attempt to optimize the range and another variable, such as the schedule to significantly affect the third variable such as expenses. Try to answer the following question: if I want to develop this product within the specified time, then how much can it cost me keeping to the schedule? Sometimes there is also a case that you should limit all of these three variables. Then just ask yourself if you have a predetermined budget for the project, how long can its completion take?
In most projects, however, it is that the cost and the time is limited. Then you can manipulate the scope of the project. For most organizations producing software, the cost typically determines the amount of resources that can be spent on the project and the budget is estimated always after the release of a specific version. So, if the negotiation is one thing, namely the scope of the project, then this the number of functions that can be delivered effectively in a given period of time. One of Brooks’ rights is: The more things you add to a project, the more delayed its implementation.
Let us now see how all the variables can work together from the beginning of the project. The aforementioned right of Brooks refers to any project even before its physical execution. Sometimes it is the case that we have no limit to the amount of costs that may be used for the implementation of the project and can be moved to any area of the project at any time. And so in this case we know that we can reduce the overall schedule by adding specific resources to the project. However, here there is some trap because each added resource improves our schedule to a lesser extent, even though it still reduces the calendar time. And here again, another right applies, namely the right of net revenues, which says that each additional increase to a lesser extent, contributes to the whole. However, at some point, something terrible happens. Namely, each additional resource or resources do not contribute to the completion of the project within the specified schedule. When do we come to this point?

Empirical research in the field of project management has shown that the optimal amount of resources that can be destined to the project to reduce its calendar time, is usually the square root of the number of person-months. So if one person will carry out the project for 10 years, or 120 months, then providing 11 people to the project should shorten it to 11 months. So every large number of resources that can be allocated to the project only really improves the atmosphere, but does not improve team performance. Besides, sometimes it can occur that calendar time completion of the project will increase rather than decrease.

Too many resources  may extend the project indefinitely
How can you see that this is true? First, each team has an impressive demand for internal communications. The complexity of this process and the same messages can be very large if we add too many people to the project team. Communication also requires additional time and resources. Secondly, there are many dependencies in the case of tasks that arise within a given team. Mostly, it so happens that the starting points across tasks are entry points for other tasks. At some point you can no longer divide certain tasks into smaller ones, to allow them to work on two people. So sometimes it so happens that a lot of people in the project means more idle or more  off-top communication, which can really break down and lengthen each project.
So, too many resources are in fact dangerous to the project and will extend the delivery time running the software. Remember the law of diminishing returns. At some point, every new resource will negatively affect the project.

Performance factors

In the project planning process each project manager must usually determine the scope of work required as well as resources and work schedule, and then explain it to all management. There are many of these factors, aren’t there? It is much better to introduce an additional marker called factor productivity or the productivity factor. What is the productivity factor? Suppose that you have to work over a period of 10 man-months, and so how long will the project take in terms of any person employed in full-time employment? Believe me that much longer than 10 months, because no one achieves 100% productivity.

Our experience shows that only 25% of projects end with complete success. Another 25% end in complete failure. In contrast, 50% of the projects end someday, but usually exceed the schedule or budget by 100%. Of course we know that it is not the projects that fail, but the people who run them. What is the conclusion? People usually cannot effectively manage projects.

Several other factors are added to this. The period of ten person-months does not include, for example, leave, holidays, sick leave, or staff meetings. There are also many other factors that lead to lower efficiency and increase the number of man-months.
Productivity factors will of course vary depending on the organization and the individual employee. Contractors and subcontractors are generally more productive because they do not have to worry about administrative functions in which staff must attend. Typically, a rate of yield is calculated at 60%, which means that the employee is available only for three days a week. Therefore ten person days can become  seventeen, and ten person months can be 17 calendar months.
We achieve a much better coefficient of performance , if we hire contractors specifically to carry out certain tasks. In this case, the factor may be classified at 80%, but you can hype it to 90% if it can be done for individuals doing overtime. Most contractors will be happy, because they will earn more, they will not have to work after 60-70 hours in the week before the deadline.
In order to convert correctly, simply divide the number of expected person-units by a factor of productivity. For example, for ten person-months, this amounts to 16.67 or, if you prefer, 17 months. It’s simple, right?

Przeczytaj ten artykuł w wersji polskiej: http://www.businessmantoday.org/zarzadzanie-proj…mi-w-organizacji/

Zapisz

Zapisz