How to manage projects universally
For a better understanding of the article, it is advisable to first familiarize yourself with the main current approaches
Every business, one way or another, faces the question: how to implement projects. In a modern, rapidly changing world flexibility – is simply a necessity. This is why the agile philosophy has been used so often, but high-level action plans still arise and wedge mixes different models, methodologies and philosophies. The larger the project, the more complex and confusing it is. Let's try to figure it out.
The catch is that the world is multifaceted and often the approach to project management depends on such things as:
business areas
specific project or product
scale and scope of work
accuracy of requirements
people at different levels of the company
customer and desired result
Where one will work, the other is out of place. This has all been written down hundreds of times, of course, and seems obvious. Then what is the question.
But is everything really so unstable and individual, and is there really no general “working” approach?
If you look closely, you can see that there is a certain universal Part. From such parts at different levels of abstraction I made a template, which, I hope, will greatly simplify life for many.
It looks like this schematically, I’ll try to explain how to work with it.
For a qualitative understanding, I divided projects into several types, the numbers are relative.
By scale and length of the project:
Simple (up to ~3 months)
Medium (from ~3 months to ~1 year)
Complex (from ~1 year to infinity)
According to the accuracy of the goals:
Accurate (tenders, project duplicates, product shipment – the goal is clear and fully understood)
Vague (everything else where the goal seems to be there, but what exactly it should look like is not clear)
Here I will superficially recall some standard models and methodologies and their main feature:
Model is the structure by which we work.
Methodology is the way we work and the set of principles we adhere to.
Philosophy is a “lifestyle”.
..
Spiral (spiral metamodel) – includes several SDLC models, for example, iterative (cycles), while focusing on risk analysis.
Iterative (iterative model) – step by step we improve the “big picture”. At each iteration cycle we provide the result.
Incremental (incremental model) – at each step we make 1 piece, but entirely.
Waterfall (waterfall or cascade model) – classic – “step by step”, until the previous one is done, we don’t start a new one. We are not changing the requirements.
Scrum — methodology. One of the options Agile — philosophy. In this case, we use iterations (cycles) usually – a couple of weeks. And we approach everything “flexibly”. We see each other a lot and discuss how things are going so that we can stay informed and respond quickly.
Now let’s take, as is customary, a major project with the Mona Lisa and begin to figure it out.
So let's imagine what's in front of us “vague project»
Since the picture of our world is changing rapidly, make concrete plans (model Waterfall) for large projects – a very self-confident thing, especially in current realities. Even large-scale engineering government orders are controversial. But the top-level ones business goals project – it is possible and even necessary.
From the spiral (metamodel Spiral) took a beautiful name and risk analysis. For what? Well, as for me, the reality is that without risk analysis at every major business step, you can end up in a puddle. Of course, this is not necessary.
..
Conclusion: This piece can be used in any projects for top-level business purposes.
And now the same level of abstraction, only in the context of “exact project” In this situation, we have more explicit goals. For example: a tender for a charging station for electric vehicles “Moscow Energy” – we have a clear specification and just need to do it. At the same time, within the project itself, we are free to do what is more convenient, faster, cheaper, etc.
Naturally, the larger the project, the greater the risks. Accordingly, we need to rely more on business goalsnot on clear result every step. It’s variable here, because the boundaries of the project’s size are blurred.
Conclusion: We use this part in “precise” projects, medium-large (sometimes), medium, small.
Let's move on.
Let's go down one level of abstraction. Between the huge steps there are medium ones. And again, the larger the project, the more massive the structure, which is logical. Let's keep in mind “vague project.”
The world moves iteratively (cyclically) in time (model Iterative) and ends with a new cycle, both in history and in nature. Therefore, I propose to use a visual hint and use this as a basis for almost any project. Why?
Every customer wants to know “what’s there”, whether it is internal or external, state or non-state. This approach creates more confidence both within teams and on the side of managers. More visible results – less stress – often more action. And, of course, it all comes down to optimization resources and clarifications requirements at the customer's. Classic…
That's why all these wonderful control schemes arose. Well, partly to “cut money” with fashionable words. (about some methodologies and philosophies)
Now let’s add a little risk analysis here (model Spiral) yes, yes, she again, because not only business goals sometimes need to be reassessed over a long distance, but also basic steps. By tracking progress, we can more adequately predict what will happen in the end, what time and amount still needs to be invested, and where we are falling short. (again optional)
Conclusion: you can use this almost everywhere, somewhere as the basis of a project, somewhere as a nested “Waterfall” level of abstraction. For large, medium-large, medium, some small projectsas well as various products. Except, for example…
…this is the option – we return the context “exact project” Attention to the magical Mona Lisa. This is a situation where there are different departments, domains, teams, etc. They do something in very different modes and at every step – this is a whole project.
For example, we are building a rocket. In this vein, we cannot assemble the entire structure at once, and then, in fact, finish each module on the knee and iteratively improve it. What's the solution? waterfall
Of course, looking ahead a little, you need to divide the project into incremental subprojects, that is, pieces (model Incremental). Each such piece is in iteration mode (let me remind you the current model Iterative) we finish until the moment when we need to put everything together.
Conclusion: we use it when it “does not assemble” at each iteration; as a full-fledged project, or as part of the “Waterfall” abstraction; for almost all project sizes.
Well, now hurray, lower abstraction.
So, well, here we’ll talk about how we can keep up with everything in large and medium-sized projects. The main disadvantage of waterfall and, sometimes, incremental is Not flexibility and “step by step” which means that each one works only when the previous one has finished at least “normally”.
We eliminate the disadvantage by parallelizing the processes, as far as possible, into incremental pieces (model Incremental). Now we have a larger piece divided into smaller ones. Where is each team, etc. He's obviously doing his own thing.
In sum with the previous abstraction, we actually have Evolutionary model – increments are built into iterations.
RAD (branch from Incremental) – when we have a lot of money, we can afford very good specialists or when we have a lot of money and a lot of automation, we use it to do even better and even faster. It depends on what RAD it is.
Conclusion: I’m sure, and it’s clear, we use it in a “composition” when there’s a lot of things to do and people doing.
And the last push. Which was reached by the most interested and “scrolling” people
I think everything is clear from the picture, but just in case: we insert an iterative model into an incremental one, in cases where the “small pieces” are extended in time or are simply large in reality.
Methodologies Scrum, Canban and model V these are simply examples of execution at the lowest level. Also sometimes good here Waterfall separately or as part of Scrum, or as “instructions”.
Do not forget that this is all “universal” – it cannot cover all needs. This means that we adapt better to some tasks. Introducing how modular system where there is warpinto which we can throw additions.
For example, the principle of the model V – testing, you can wedge it into higher-order abstractions, if it makes sense. Or use the same model, only for QMS — quality management.
Methodology RUP – can be included in the average abstraction at the level Iterativeif you need OOP and an emphasis on architecture. (it is in principle quite flexible and was created as a “universal solution”, like this template)
Let's summarize the article:
For the most part, a project consists of subprojects with nesting (Large‑(Medium Medium‑(small small small))).
At the highest level – business goals, or precise designs
At the average level – iteratively with the application of suitable “modules” – testing, risk analysis and calculation of the required number of steps.
At a low level – nesting of pieces – increments at each iteration step.
At the lowest level – increments, we do as much as possible flexible, using a suitable structure.
Regarding philosophies and some principles, this is a slightly different question, as for me.
Well, that’s all, thank you for reading, I’ll add – “all this is individual”) Naturally, there are a lot of exceptions, without them you can’t get anywhere… Everything that can be “generalized” for universal template – I hope I conveyed it clearly. This is also thanks to people who make the most of their experience and write articles, thank you if you read.
If there are any additions, adjustments or just comments that can help forum members or me in a deeper understanding, to improve the template, I will be glad.
You can write questions to telegram @heritager_tech, I will answer if possible.
