Resource concept in project management

    Good day. I would like to speculate on one of the well-known aspects of projects - the resource one. The premise is that if you open, for example, the textbook of Mazur, Shapiro, Olderogge "Project Management" , then there the project is immediately considered as "the process of transition from the initial state to the final - the result, with the participation of a number of restrictions and mechanisms."

    That is, at first there was an idea (site, software, service rendered), then its concrete material 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 production, then as a series of transformations for sure.

    Hereinafter, by the resource we mean any object whose presence is necessary to achieve the project result. Including intermediate artifacts of the project will be resources for it.

    Common IT Project Resources

    What can be attributed to resources? In addition to the obvious “money” and “time”, their derivatives can also be attributed:
    1. Toolkit (starting from a banal workplace and ending with stands and development tools) - requires money
    2. The staff and their specific knowledge require money (he is, yes :)), and, in the case of knowledge, maybe time
    3. Customer bases and customer loyalty - requires both time and money
    4. 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 are talking about the manufacture of devices, then the assembled prototypes and directly materials for production (finished components)

    To go deep into the concept either by examples or in theory makes no sense. It is clear that any tangible or intangible object (or even animate) that is necessary to achieve the goal can be denoted by the concept of a resource. As in any system, in fact, the resources themselves are important not so much as their interconnection.

    Let me give you an example from a game building: for the finished result you always need both art and a code. You can write code without art, you can’t test it. You can draw art without a code, but it’s practically impossible to see “live” 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 one, and general visual art is whipped up by renders of art development tools (without any inter-action). In the end, everything merges in ecstasytogether. Here are some things: the quality of the final result depends on the availability of artistic imagination among programmers on the one hand, and the understanding of the structure of software systems by artists. Fortunately, such resources can be replaced by close communication.

    The relationship of the project management methodology with the chain of resource transformations

    Iterative (with timeboxes, I will call it further generically, Agile) and cascading approaches differ in terms of resource conversion, mainly in how they manage with time. In one case, it is "cut" into equal pieces, in the cascade not. 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. Moreover, the number of results is obviously different, especially the shorter the timebox.

    All of the above is quite obvious, but now we can note the following: the expenditure of resources is different. In the book already mentioned above, resources are divided into two types:
    1. Unreproducible, stockpiled, accumulated - “energy” (finance for IT projects),
    2. Reproducible, non-stockable, non-accumulating resources - “capacities” (people for IT projects).

    While the cascade approach uses both “power” and “energy” as needed, flexible approaches use “power” to the full, dosing 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 (they are the same resources) do not require constant alterations during the project. Thus, the fact of using a flexible approach does not justify abandoning the development of architecture and the sequence of functional implementation - and the latter is not at all based on user 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 document-based ERP; for B2C, a website 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 the charts are not read well due to the fact that, at first glance, “everything is connected with everything”, then they can be divided into several. But all the same, it is connected with everything, it is inevitable. The projects are such that the previous results are used in the subsequent ones, as during the construction of high-rise buildings they build from the bottom up (in the case of construction - due to problems with gravity, in the case of projects - because of inevitable cause-effect 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 its diagram hides the absence of some resources that are in the second.

    Instead of a conclusion - risk management in the project through the prism of the resource chain

    "A risk-free plan is a set of wishes, a risk-free plan is a casino." ((c) mine).

    Risk is an event that will divert project indicators from the right ones. The risk affects the final result of the project (either it was not on time, or of poor quality, or it got out of the budget). Now carefully follow the hands :)

    Statement. The sequence of creation and application 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 deviating the value from the planned one. The value 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. It follows from this that a change in the composition of resources and their sequence leads to a change (graph) in the indicator values. This also implies that there are no projects without risk (since the resources in fact never correspond to the planned ones). The “content” of the resource itself cannot be called a risk generator, since changing its “content” we change the resource (for example, the database is not MS SQL Server, but Firebird are two different resources). [End of evidence]

    If all of the above seems like some kind of theory, think about the fact that this theory appears in both the big and the small. Even when you decide which task to take from the backlog first, of the two options, the best is the one that will require the creation of fewer intermediate “ejection” resources (stubs, etc.). Even if you are trying to decide which is better - organize the introduction of hundreds of jobs in different offices based on geographic separation, or functional - look at which option of the resource chain will deviate your indicators from the desired fewer (the choice depends on the selected pair of the three indicators of the project triangle) .

    Thanks for reading. All successful projects!

    Also popular now: