Resource concept in project management
Good day. I would like to speculate about one of the known aspects of the projects - the resource one. The prerequisite is this: if you open, for example, the textbook by Mazur, Shapiro, Olderogge “Project Management” , then immediately the project is considered as “the process of transition from the initial state to the final one — the result with the participation of a number of restrictions and mechanisms”.
That is, at first there was an idea (of the site, software, service rendered), then its specific real implementation.
Implementation, obviously, is a chain of transformation of some resources into others, like any production. This post will be devoted to the consideration of IT projects, if not as a production, then as a series of transformations for sure.
Hereinafter, a resource will be understood as any object, the presence of which is necessary to achieve the result of a project. Including the intermediate artifacts of the project will be resources for it.
')
What can be attributed to the resources? In addition to the obvious "money" and "time", you can also include their derivatives:
The latter, in turn, are, for example:
Strongly go into the concept neither in examples nor in theory there is no point. It is clear that any material or non-material object (or even animate), which is necessary to achieve the goal, can be designated by the concept of a resource. As in any system, in fact, it is not so much the resources themselves that are important as their interconnection.
I will give an example from igrostroy: for the finished result, both art and code are always needed. The code without art can be written, it is impossible to test. It is possible to draw art without a code, but it is practically impossible to look “alive” at the general result of art (vision and interaction) without a code. What to do? Most often, they write code with stubs from art, which repeats the basic properties of the finished product, and general art artwork is whipped up with renderers of art development tools (without any interaction). In the end, everything mergesin ecstasy together. There are some things to do: the quality of the final result depends on the presence of the artistic imagination of the programmers on the one hand, and the understanding of the design of software systems for artists. Fortunately, such resources can be replaced by close communication.
Iterative (with timeboxes, I will call collectively Agile below) and cascade approaches differ from the point of view of resource conversion mainly by how they manage with time. In one case, it is "sliced" into equal pieces, in the cascade there is none. Iterations can be both there and there, the whole question is what kind of intermediate results the project creates: in the case of flexible approaches, we have a final incomplete product at each iteration, in the case of a cascade, we have separate functions / modules. The number of results is obviously different, especially the shorter timebox.
All this is quite obvious, but now we can note the following: the use of resources is different. In the book already mentioned above, resources are divided into two types:
While the cascade approach uses both “power” and “energy” as needed, flexible approaches use “power” to the fullest, dispensing appropriately “energy”. In order for the second case to guarantee us no greater total consumption, it is necessary that the intermediate results produced by iterations (the resources are the same) do not require constant rework during the project. Thus, the mere fact of using a flexible approach does not justify abandoning the development of the architecture and the sequence of implementation of the functionality — and the latter is not at all based on the user's priorities if you want to optimize the project.
Consider a couple of options - B2B and B2C. For B2B, we will consider a development project for something like a simple ERP document flow, for B2C, a site-exchange where visitors order and buy services from each other.
The arrows in the diagrams reflect the sequence.
If diagrams are read poorly because, at first glance, “everything is connected with everything,” then they can be broken down into several. But everything is still connected with everything, it is inevitable. The projects are such that the previous results are used in subsequent ones, as in the construction of high-rise buildings they build from the bottom up (in the case of construction, because of problems with gravity, in the case of projects, because of the inevitable causal relationships). Such a resource as "time" is not given at all, so as not to litter everything with arrows.
And yes. If (suddenly) it seems that the flexible approach is “slimmer”, then the primitiveness of his diagram hides the absence of some resources that are in the second.
"A plan without risks is a set of wishes, a risk without a plan is a casino." ((c) mine).
Risk is an event that rejects project performance from necessary. The risk affects the final result of the project (either it is not on time, or poor quality, or got out of the budget). Now we carefully monitor our hands :)
Statement. The sequence of creation and use of resources, as well as the presence or absence of the resources themselves in the resource chain, determines the level of riskiness of the project.
Evidence. Consider an arbitrary indicator, its risk will be the possibility of deviation from the planned value. The values ​​of the indicator at some point in time is a function of the resources involved up to this point, at the end of the project - all resources. From this it follows that a change in the composition of resources and their sequence leads to a change (graph) in the values ​​of the indicator. This also implies that there are no projects without risk (since the resources in fact never correspond to the planned ones). The “content” of a resource itself cannot be called a risk generator, since changing its “content” we change a resource (for example, the base is not MS SQL Server, but Firebird are two different resources). [End of Proof]
If all of the above seems to be a theory, think about the fact that this theory is manifested in the large and the small. Even when you decide which backlog problem to take first, of the two options, the one that requires the creation of a smaller amount of intermediate resources “to emit” (plugs and other things) is better. Even if you are trying to decide which is better - to organize the implementation in hundreds of workplaces in different offices based on geographical separation, or functional - see which version of the resource chain will deviate your indicators from less desired (the choice depends on the selected pair from the three indicators of the project triangle) .
Thank you for reading. All successful projects!
That is, at first there was an idea (of the site, software, service rendered), then its specific real implementation.
Implementation, obviously, is a chain of transformation of some resources into others, like any production. This post will be devoted to the consideration of IT projects, if not as a production, then as a series of transformations for sure.
Hereinafter, a resource will be understood as any object, the presence of which is necessary to achieve the result of a project. Including the intermediate artifacts of the project will be resources for it.
')
Common IT Project Resources
What can be attributed to the resources? In addition to the obvious "money" and "time", you can also include their derivatives:
- Toolkit (starting from a banal workplace and ending with stands and development tools) - requires money
- The staff and its specific knowledge - requires money (he is, yes :)), and, in the case of knowledge, time is possible
- Customer base and customer loyalty - requires time and money
- Any artifact “semi-finished product” produced in the project requires both money and time.
The latter, in turn, are, for example:
- Program code
- Documentation (TK, user and any other)
- Deployed Solutions
- Information in databases, customer information
- If we talk about the production of devices, then the collected prototypes and materials directly for production (finished components)
Strongly go into the concept neither in examples nor in theory there is no point. It is clear that any material or non-material object (or even animate), which is necessary to achieve the goal, can be designated by the concept of a resource. As in any system, in fact, it is not so much the resources themselves that are important as their interconnection.
I will give an example from igrostroy: for the finished result, both art and code are always needed. The code without art can be written, it is impossible to test. It is possible to draw art without a code, but it is practically impossible to look “alive” at the general result of art (vision and interaction) without a code. What to do? Most often, they write code with stubs from art, which repeats the basic properties of the finished product, and general art artwork is whipped up with renderers of art development tools (without any interaction). In the end, everything merges
Interrelation of the project management methodology with the chain of resource transformations
Iterative (with timeboxes, I will call collectively Agile below) and cascade approaches differ from the point of view of resource conversion mainly by how they manage with time. In one case, it is "sliced" into equal pieces, in the cascade there is none. Iterations can be both there and there, the whole question is what kind of intermediate results the project creates: in the case of flexible approaches, we have a final incomplete product at each iteration, in the case of a cascade, we have separate functions / modules. The number of results is obviously different, especially the shorter timebox.
All this is quite obvious, but now we can note the following: the use of resources is different. In the book already mentioned above, resources are divided into two types:
- Irreproducible, stored, accumulated - “energy” (finance for IT projects),
- Reproducible, non-stocked, non-accumulative resources are “capacities” (people for IT projects).
While the cascade approach uses both “power” and “energy” as needed, flexible approaches use “power” to the fullest, dispensing appropriately “energy”. In order for the second case to guarantee us no greater total consumption, it is necessary that the intermediate results produced by iterations (the resources are the same) do not require constant rework during the project. Thus, the mere fact of using a flexible approach does not justify abandoning the development of the architecture and the sequence of implementation of the functionality — and the latter is not at all based on the user's priorities if you want to optimize the project.
Transformation Chain Examples
Consider a couple of options - B2B and B2C. For B2B, we will consider a development project for something like a simple ERP document flow, for B2C, a site-exchange where visitors order and buy services from each other.
The arrows in the diagrams reflect the sequence.
B2B "ERP" Agile
B2C "Exchange" Cascade
If diagrams are read poorly because, at first glance, “everything is connected with everything,” then they can be broken down into several. But everything is still connected with everything, it is inevitable. The projects are such that the previous results are used in subsequent ones, as in the construction of high-rise buildings they build from the bottom up (in the case of construction, because of problems with gravity, in the case of projects, because of the inevitable causal relationships). Such a resource as "time" is not given at all, so as not to litter everything with arrows.
And yes. If (suddenly) it seems that the flexible approach is “slimmer”, then the primitiveness of his diagram hides the absence of some resources that are in the second.
Instead of conclusion - risk management in the project through the prism of the resource chain
"A plan without risks is a set of wishes, a risk without a plan is a casino." ((c) mine).
Risk is an event that rejects project performance from necessary. The risk affects the final result of the project (either it is not on time, or poor quality, or got out of the budget). Now we carefully monitor our hands :)
Statement. The sequence of creation and use of resources, as well as the presence or absence of the resources themselves in the resource chain, determines the level of riskiness of the project.
Evidence. Consider an arbitrary indicator, its risk will be the possibility of deviation from the planned value. The values ​​of the indicator at some point in time is a function of the resources involved up to this point, at the end of the project - all resources. From this it follows that a change in the composition of resources and their sequence leads to a change (graph) in the values ​​of the indicator. This also implies that there are no projects without risk (since the resources in fact never correspond to the planned ones). The “content” of a resource itself cannot be called a risk generator, since changing its “content” we change a resource (for example, the base is not MS SQL Server, but Firebird are two different resources). [End of Proof]
If all of the above seems to be a theory, think about the fact that this theory is manifested in the large and the small. Even when you decide which backlog problem to take first, of the two options, the one that requires the creation of a smaller amount of intermediate resources “to emit” (plugs and other things) is better. Even if you are trying to decide which is better - to organize the implementation in hundreds of workplaces in different offices based on geographical separation, or functional - see which version of the resource chain will deviate your indicators from less desired (the choice depends on the selected pair from the three indicators of the project triangle) .
Thank you for reading. All successful projects!
Source: https://habr.com/ru/post/290506/
All Articles