Microsoft Project delenda est
In the lives of many inhabitants of the software industry, sometimes the moment comes when they have to draw a project plan. People who have heard about project management, read books on this topic (especially books that did not describe a specific industry), and also studied project management anywhere (at an institution of higher learning, on courses, etc.) are most often automatically selected for create this plan Microsoft Project. Sometimes the use of MS Project is imposed by management, client, process standards in a company, etc.
For software projects, the choice of MS Project is usually extremely unfortunate, and below we will explain why, but first we recall a few simple facts about how software projects work, especially in the context of custom development.
The author apologizes in advance for the huge amount of professional slang Anglicisms used in the text, but he believes that it’s better with them than without them.
The author focuses on projects executed mainly by hired employees within professional companies, not too small and not too large. Some explicit and implicit assumptions underlying the text may not work in other organizational contexts, for example, in the case of startups, freelancing or global mastodons with hundreds of thousands of employees. This applies particularly to two assumptions:
')
This chapter is by no means a complete description of the software project management discipline. It describes only the most basic level of complexity and introduces some concepts.
So, if you do not go into details, the project must first be sold, and then executed.
During the sale, we must use the generated artifacts (estimeyty, project plans, proposals, etc.) to answer the following questions to ourselves and the client:
Other issues that often lie beyond the actual "estimeyta" in the narrow sense, but critical to generate a complete project plan:
Besides:
During the execution of the project, we monitor what is happening with the help of project management tools and periodically (in most cases with a period of 1 to 7 days) we do a status review and answer the questions:
Usually in the project execution phase the following is true:
Best practices in the execution of the project include:
Developing a project plan in MS Project is similar to developing a C / C ++ software system. In skillful hands, this tool is very powerful, but without special efforts and skills you can easily get a difficult-to-change, poorly organized result with a lot of bugs. In addition, for most of the problems encountered, the power of this tool is excessive — that is, We do not receive much added value, and we have all the drawbacks and limitations in full growth. This tool also has fundamental limitations and defects, which fundamentally reduce productivity when working with it, regardless of the qualifications of the person who uses it.
What are the main disadvantages, limitations and risks encountered when working with MS Project by people with different levels of qualification and experience? To indicate the level of “coolness”, we will use the simplest three-level grade ladder, consisting of Junior, Middle and Senior levels.
“Junior” usually sees MS Project for the first time in his life and does not know anything about him. He may have seen plans in MS Project made by older colleagues in the past, but he doesn’t have a sufficient understanding of what he saw besides the general visual form of Gantt chart.
Quite virgin beginners often use Project as Excel - they enter a task list (often not even hierarchical), assign watches to tasks and send it to the review as a draft estimate.
A more common option when the author of estimeyta saw in his life Gantt chart and knows that the "sausages" should be placed from top to bottom, from left to right. In this embodiment, we get one or more linear bundles of sausages, fastened together through auto links.
It is important that the newbies do not know or are clogged to resource allocation and the project simply does not have any resources at all. Lack of resources in the plan, made in MS Project, is a key feature of the junior.
Middle usually listened to courses or read a book, but does not have his own experience with Project (or has insufficient). He is aware of common rules and principles, but often forgets about the devil in detail. In addition, the “middle” most often does not have the skills to create the “architecture” of the project and either does not think through large-scale elements of the plan, or does not know how to express them by means of MS Project.
The most frequent defects of the plan from the middleware are poorly organized architectonics of the plan and uneven loading of the team (in terms of the Project, at the level of work assignment).
By “poorly organized architectonics” we understand the structure of the plan (including the timeline and work breakdown structure), in which high-level elements of the project plan, such as phases and milesstones (for the timeline) and tracks (tracks , they are subcommands, feature teams, etc., for WBS and team organization). MS Project in itself does not push the author of the plan to think on these topics - moreover, MS Project simply does not have most of the relevant concepts and “primitives” higher than individual tasks and resources.
In reality, people in the project team rarely work alone and completely independently of each other. The work of the team is at least synchronized by delivery milestones, before which you need to perform certain actions. In teams larger than a certain size, subcommands or tracks are often distinguished (according to the vertical or horizontal principle, that is, either in parts of the business functionality of the system, or in parts of the technical implementation — for example, frontend track, reporting track, QA team, etc.). A well-structured project plan must take into account these natural patterns.
If we do not take them into account, as a typical middle does, we usually get a large number of overlapping pieces of work and no structure of iterations and releases that are not clearly visible. In more severe cases, the author does not follow any logic at all in the relative location of the tasks, as a result of which individual tasks become scattered throughout the timeline, and most of the summary tasks are stretched to the full length of the project.
A more advanced author might even have thought about the team structure, but he doesn’t have so many ways to express it in Project - at best, these are the names of resources like “Database Developer 1”. Authors who really care a lot about clarity and visibility can use color to visually express the difference between tracks — usually painting sausages for tasks from different tracks in different colors.
This also includes the manner of using dependencies aka links not to express the essential dependencies between tasks, but to place the tasks in the plan in the correct order. The auto-link feature, which automatically creates a link between two consecutively placed tasks, directly stimulates this mindless use of links. The lack of a clear understanding of the semantics of links in the middle after several iterations of editing leads to erratic flashing of the plan with arrows running in all directions. A typical manifestation of the inept use of links is the links that have no real meaning between tasks in different summary tasks or between tasks located at different levels in WBS (such links may make sense generally, but the corresponding situations are found in typical planning rather rarely - erratic the arrows from the mixing of automatically linked tasks usually drag along the middle plan everywhere). The extra arrows themselves are harmless, albeit ugly, but turn into a terrible problem when you try to level up the load in volumetric planning.
The problem with torn downloads is actually systemic and makes life difficult for both beginners and experienced Project users. We'll talk about the experienced later, and here we will describe what the typical mistakes are made by the “middle”. These errors are simple - “Middle” often just forgets to see what the resources load in the resulting plan, and as a result this plan violates the rule we mentioned above - “most people work on the full-time project without interruptions”. A characteristic symptom is the boot numbers in resource usage view that are less than or greater than 100%. The problem with overloading (> 100%) is usually solved by applying leveling and advanced midli know how to do it and often recall it (since overallocation is usually visually noticeable on the Gantt chart), but leveling the tasks of some team members usually creates more holes in others . Such a plan gives rise to a lot of practical problems, since it obviously does not describe a realistic project implementation and gives distorted ideas about all the parameters of the project at once - and about the price (which is usually underestimated), and about the actual deadlines for the execution of tasks (which can both be overstated and underestimated) , and about the actual download and resource requirements.
A separate error of the "middle" is a fuzzy distinction between the duration (that is, the absolute time measured in hours) and work (that is, the labor costs measured in man-hours). Here, even advanced MIDLs are lurked by the idiotic Project trap, which is that by default the Duration field is displayed in the grid, and tasks have the default type of fixed units or fixed work and are entered as effort-driven. A typical sign of an experienced "senier" is that he understands these differences and at least enters estimates in the Work field (and ideally changes the default options in his copy of Project and decisively changes the type of all tasks during review and editing).
About the artificial intelligence Project, tormenting the "seniors", we will talk below. In the case of "midles", the nondiscrimination between hours and man-hours leads to a huge number of strange and not always clearly noticeable distortions of the planning parameters at the moment when the author begins to assign resources to tasks.
Another big problem with clocks and man-hours is that, based on practical experience, in their understanding of Project, 90% of clients do not rise above the base level of "middle" and often do not understand which column to look at and what is in this column written by When presenting full planning to Project, characteristic questions from such clients are, for example, “you said that the project will last four weeks, and the total work for some reason you have 560 hours - why are you cheating me?”.
"Seniors", i.e. people who have mastered all the necessary features of the Project, and also have a clear understanding of what they want to express with the help of the Project, begin to suffer from the fundamental shortcomings of the Project as a tool and an expressive means.
The problem with tattered loading does not go anywhere and often gets up to its full height even with bona fide MIDL. Part of it is explained by the fact that not everyone clearly remembers the type of task in Project. Part of the reason is the “artificial intelligence” built into Project and which until recently had a tendency to become more and more sophisticated from version to version.
The task of artificial intelligence in the Project is to automatically change some of the parameters of tasks when manually or automatically changing others. A classic example is halving, tripling, etc. the duration of an effort-driven task when assigning a second, third, etc. to it resource The number of scripts of this kind inside Project is quite large. The behavior of the Project in some of them is governed by the settings (some of which are the settings of a specific copy of the Project on a particular machine, and some are saved in the MPP file and transferred between the machines). Not all scenarios and rules are equally well documented, with some settings affecting rather heterogeneous scenarios, etc., etc. In many scenarios, Project behavior seems counterintuitive. In general, this part of the Project is prohibitively complex and it can be stated with a high degree of confidence that the majority of Project users cannot predict all manifestations of artificial intelligence in the course of work and are often not ready for them.
“Midly” most often remain in happy ignorance about the changes that Project makes invisibly for them. The fate of the "seniors" is harder - after a long editing experience in Project of their own, and especially those of others, of large volume, they learn to wait for their tool for sudden filth and periodically check that Project has not spoiled anything in the wake of their changes. The litmus test is the load observed through the resource usage view — unexpected and illogical distortions of the plan made by automatic changes usually manifest themselves as deviations in the level of resource utilization or in terms of the beginning and end of the work of the resource in the project. “Senjor” usually tries to draw planning with observance of simple basic architectural principles (besides uniform continuous loading, it is important that people engaged in related tasks aka in one track start working in a project and are released at the same time) and the deviation from these principles can be seen quite easily in resource usage view.
It is easy to notice the distortion introduced by the system, but it is often quite difficult to correct it, especially in projects of large size or complex structure. Undo often does not help - the manual change that led to the problem rolls back, but the deformity introduced by artificial intelligence remains and has to be corrected separately, risking running into other automatic changes. In certain situations, artificial intelligence becomes stubborn and does not allow to correct the shoals created by it.
Even when editing not the most difficult plans, you need not to forget and not allow the artificial intelligence pranks with fairly simple operations such as transferring tasks from one place to another. Simple, but equally annoying, traps such as auto-link, which we discussed above, even with a simple copy-paste, can create an extra connection between tasks or break the desired one. Some "midley", prone to exploring all the options of a complex system, can include on their machines dangerous and destructive features such as automatic "optimizing" the assignment of resources (meaning it makes sense when planning a Stroybat platoon with shovels) - even if the "seigneur" will inadvertently to review such planning (especially right on the middle machine), the Project will gladly mix resource allocations and create a mess that doesn’t even have a trace of meaning.
But especially unexpectedly, the harmfulness of artificial intelligence manifests itself when editing planning, in which some tasks are already marked as completed, or, to put it more scientifically, tasks in which data on actuals (actual work, actual duration, etc.) appeared. It is in such situations (although not only in them) that artificial intelligence begins to behave especially cynically and make changes in planning that are difficult to tolerate and even harder to roll back. Vivid examples are the sudden creation of gaps in tasks, the distortion of the planned load of resources within a task, the sudden transfer of a task or group of tasks after all others, and the persistent reluctance to insert them back into place, even using manual leveling. An experienced user anticipates such troubles and usually knows some tricks to avoid them (such as disciplined use of task constraints), but in general when working with volumetric planning, especially including actuals, more and more time usually begins to go to fight with the tool, rather than for meaningful editing. At some point, even the “seigneur” gets tired of fighting, gives up, gives up and sighs, sends colleagues or clients a planning in which resources are very often at 83.58% on Friday and 16.42% next Saturday.
As a bonus, we mention quantum effects that occur after several iterations of joint work on a large MPP file (500 tasks), in which a literal colleague decided to fix the beginning of the working day in the calendar from the default 8:00 to something “more appropriate our realities ", like 11:00. A beginner of a “seigneur” who looks over planning, usually on a scale of days or weeks, will be slightly surprised by the strange manner of part of the tasks jumping to the next business day without any visible reason. Looking into the daily resource usage view, he sees in general a completely flat load on each resource, with strange tails, say, 62% in front and 38% in the back. And only by increasing the scale up to the clock, he will be terrified and realizes that if he wants to bring it all into a divine form, an hour or a half of boring handwork awaits him. Usually, the “seigneur” decides not to be a perfectionist (because there are more important things in life than quality planning) and continues to work with what he has. Nudging later on the more sinister manifestations of artificial intelligence, described above, which in combination with low-level burrs on the calendar often look especially strange and are treated particularly tedious.
Continuing the C / C ++ development metaphor (perhaps slightly outdated today), Project’s full-fledged use in complex scripts begins to look like an attempt to build a very large and complex system written in C / C ++ without using make / ant and having libraries for which the correspondence between the header (.h) and binary (.a / .lib and .so / .dll) files at our disposal is not guaranteed. Theoretically, it is possible to do this, but it may require very noticeable efforts and good qualifications, and the assembled system may have critical bugs.
After discussing the problems and pitfalls of MS Project, the question may arise - why did Microsoft develop and promote such rubbish? We are far from blaming Microsoft for being unprofessional and malicious. Before we continue to discuss the problems, let us briefly touch upon what MS Project is suitable for, and try to explain a number of its features, which at first glance look glaring.
The main idea here will be quite simple and actually coincides with the main thesis of the whole article: MS Project is not well suited for planning and maintaining minimally complex software projects. This does not mean that it is equally inadequate for projects in other areas of human activity. MS Project was created as a universal project management tool - and project management as a management technology is used not only in software development. There are areas of human activity and the scale of projects in which MS Project can be applied without much risk to turn planning into a smoking mountain of tangled pasta. This mainly concerns scenarios where one of the conditions is fulfilled:
For a minimally complicated project in the field of software development, none of these conditions is usually fulfilled, although very simple projects may not change in the course of execution and / or contain only about 30–40 tasks and 1–2 executors (in the latter case the truth is that “Heavy” tools like MS Project still raise doubts).
As for those Project features that seem meaningless or even malicious, any person familiar with the history of the software industry should understand that the reason lies in the evolution of MS Project itself as a product - namely, in successive attempts by Microsoft to make it more and more universal, while maintaining backward compatibility with previous versions. The notorious "artificial intelligence" and other features dangerous for beginners are just a consequence:
Any experienced user can easily provide several similar examples of bloatware, led by everyone's favorite MS Word, which, as you know, 90% of users use only 10% of features. Alas, MS Project, in contrast to MS Word, is intended to describe a certain model of reality - and the excessive complexity in using the tool leads to the fact that the models are inadequate and do not serve their main purpose - they do not allow answering those questions about the project that were listed at the beginning of this article.
At the same time, we recognize that the conceptual model of MS Project really allows us to describe things that are difficult to express right away using popular alternatives (usually based on linear task lists aka backlog-style). The really useful features are of course dependencies - dependencies between tasks, the very same links. ( , ..) .
– MS Project , MPP-, MS Project . , , , , Project .
MS Project – - , , . ?
– MS Project . : , - MS Project - .
– , MS Project – - . , , , , , .
, , MS Project « » . , , , , MS Project.
, , « ». , agile, -, MS Project – . , MS Project added value – , ( Kanban board, backlog ..).
, , , , , .
– - . , . , MS Project ( ) . - – , , . (- – « » ). « » , .
reviewer' « X?» «, , Project » « , Project », . « X ?» ( ).
MS Project , , , Project - ( ). Project - , . , MPP- . , , . , baseline - «», - – « ». , , . MPP-, . MPP- , MPP- . .
- , , Project , - , – .
, MS Project. , , , , . , Project .
. , . , , , – , , , .. ( GTD), .
Project - . .
Project , . , Project - .
Project, - ( ) . , - , , Project , .
, , Project, , « ». Project high-level plan, «» MPP- . MPP-, , 10-20 , , «» , , executive summary, . - . (, ) MS Project earned value management (, , ).
, Project . , , , , VCS repository, (, VPN- , -). promotion ( ) , ( ) . DVCS Git Mercurial, « » — . , PMO, «» MS Project, , .
, , , , MS Project Gantt charts. , , Project, Visio .
, , MS Project – .
MS Project . MS Project , - , , . - MS Project , , .
, , .
For software projects, the choice of MS Project is usually extremely unfortunate, and below we will explain why, but first we recall a few simple facts about how software projects work, especially in the context of custom development.
Disclaimers and otmazy
The author apologizes in advance for the huge amount of professional slang Anglicisms used in the text, but he believes that it’s better with them than without them.
The author focuses on projects executed mainly by hired employees within professional companies, not too small and not too large. Some explicit and implicit assumptions underlying the text may not work in other organizational contexts, for example, in the case of startups, freelancing or global mastodons with hundreds of thousands of employees. This applies particularly to two assumptions:
- The members of the project team, on average, work 8 hours a day and 40 hours a week and exceptionally rarely exceed these levels by more than one and a half times.
- The main goal of the executed projects is the successful solution of the client’s business problem.
')
Business Context: How a Software Project Is Done
This chapter is by no means a complete description of the software project management discipline. It describes only the most basic level of complexity and introduces some concepts.
So, if you do not go into details, the project must first be sold, and then executed.
Sale
During the sale, we must use the generated artifacts (estimeyty, project plans, proposals, etc.) to answer the following questions to ourselves and the client:
- Scope. What will be the result of the project?
- Time. How long will the project last? At what moments what will happen (usually up to deliveries and phases)?
- Cost. How much is it? When to pay?
- Resources & Effort. What people are needed for this and at what moments? How much effort and who will go to each of the tasks or elements of the scop?
Other issues that often lie beyond the actual "estimeyta" in the narrow sense, but critical to generate a complete project plan:
- Dependencies. What materials, information, actions, etc. the project team expects from the client or from the third parties? At what moments?
- Acceptance. How do we determine that the results obtained during the project are consistent with the agreements and needs of the client?
Besides:
- During the sale and trade, estimeyt and other artifacts have to be redone several times, often in a very short time.
- Artifacts usually exist in the form of files exchanged via email.
- Customers like to see the cost breakdown according to very different criteria - especially in parts of the system and parts of functionality - and also ask the question “if you throw it out, how will the price and terms change?”.
Execution
During the execution of the project, we monitor what is happening with the help of project management tools and periodically (in most cases with a period of 1 to 7 days) we do a status review and answer the questions:
- Scope. What is done? What is left to do? What new requirements appeared, and the old ones were removed? What was delivered in past delivery milestones? What will be delivered in the future?
- Time. When will the next milestone happen? Other future milestones? End of the project?
- Cost. How many hours have been already spent, vendor money and customer money? How much is left to spend?
- Resources & Effort. What people worked and are working on the project? How much effort did they spend? What people and how much effort will be needed to bring the project to the end?
Usually in the project execution phase the following is true:
- There are new requirements and tasks, and old ones can be derived from the scopa.
- Parts of the scop can move between shipments (usually in the form of “put off to the next phase”).
- Most people work on a full-time project without interruptions, i.e. 8 hours a day, 40 hours a week, from the moment of arrival in the project until the exit from the project. Sometimes a person can work in overtime on a project, but we very rarely get into it at the estimeit stage. Part-time roles with torn loading exist, but in 99% of cases the participation of these roles does not exceed 10-20% of the total level of labor costs in the project and these are usually special roles (part-time PM, designer, etc.).
Best practices in the execution of the project include:
- Using the task tracker aka centralized PM tool, such as Jira, Rally or Redmine. The tracker is usually filled at the start of the project from estimeyta and is updated on a regular basis, and also serves as a source of information for monitoring and reports.
- Status reporting, written and oral, which includes answers to the questions listed above (as well as any other).
Degrees of initiation, they are the Circles of hell
Developing a project plan in MS Project is similar to developing a C / C ++ software system. In skillful hands, this tool is very powerful, but without special efforts and skills you can easily get a difficult-to-change, poorly organized result with a lot of bugs. In addition, for most of the problems encountered, the power of this tool is excessive — that is, We do not receive much added value, and we have all the drawbacks and limitations in full growth. This tool also has fundamental limitations and defects, which fundamentally reduce productivity when working with it, regardless of the qualifications of the person who uses it.
What are the main disadvantages, limitations and risks encountered when working with MS Project by people with different levels of qualification and experience? To indicate the level of “coolness”, we will use the simplest three-level grade ladder, consisting of Junior, Middle and Senior levels.
Junior MS Project Designer
“Junior” usually sees MS Project for the first time in his life and does not know anything about him. He may have seen plans in MS Project made by older colleagues in the past, but he doesn’t have a sufficient understanding of what he saw besides the general visual form of Gantt chart.
Quite virgin beginners often use Project as Excel - they enter a task list (often not even hierarchical), assign watches to tasks and send it to the review as a draft estimate.
A more common option when the author of estimeyta saw in his life Gantt chart and knows that the "sausages" should be placed from top to bottom, from left to right. In this embodiment, we get one or more linear bundles of sausages, fastened together through auto links.
It is important that the newbies do not know or are clogged to resource allocation and the project simply does not have any resources at all. Lack of resources in the plan, made in MS Project, is a key feature of the junior.
Middle MS Project Designer
Middle usually listened to courses or read a book, but does not have his own experience with Project (or has insufficient). He is aware of common rules and principles, but often forgets about the devil in detail. In addition, the “middle” most often does not have the skills to create the “architecture” of the project and either does not think through large-scale elements of the plan, or does not know how to express them by means of MS Project.
The most frequent defects of the plan from the middleware are poorly organized architectonics of the plan and uneven loading of the team (in terms of the Project, at the level of work assignment).
By “poorly organized architectonics” we understand the structure of the plan (including the timeline and work breakdown structure), in which high-level elements of the project plan, such as phases and milesstones (for the timeline) and tracks (tracks , they are subcommands, feature teams, etc., for WBS and team organization). MS Project in itself does not push the author of the plan to think on these topics - moreover, MS Project simply does not have most of the relevant concepts and “primitives” higher than individual tasks and resources.
In reality, people in the project team rarely work alone and completely independently of each other. The work of the team is at least synchronized by delivery milestones, before which you need to perform certain actions. In teams larger than a certain size, subcommands or tracks are often distinguished (according to the vertical or horizontal principle, that is, either in parts of the business functionality of the system, or in parts of the technical implementation — for example, frontend track, reporting track, QA team, etc.). A well-structured project plan must take into account these natural patterns.
If we do not take them into account, as a typical middle does, we usually get a large number of overlapping pieces of work and no structure of iterations and releases that are not clearly visible. In more severe cases, the author does not follow any logic at all in the relative location of the tasks, as a result of which individual tasks become scattered throughout the timeline, and most of the summary tasks are stretched to the full length of the project.
A more advanced author might even have thought about the team structure, but he doesn’t have so many ways to express it in Project - at best, these are the names of resources like “Database Developer 1”. Authors who really care a lot about clarity and visibility can use color to visually express the difference between tracks — usually painting sausages for tasks from different tracks in different colors.
This also includes the manner of using dependencies aka links not to express the essential dependencies between tasks, but to place the tasks in the plan in the correct order. The auto-link feature, which automatically creates a link between two consecutively placed tasks, directly stimulates this mindless use of links. The lack of a clear understanding of the semantics of links in the middle after several iterations of editing leads to erratic flashing of the plan with arrows running in all directions. A typical manifestation of the inept use of links is the links that have no real meaning between tasks in different summary tasks or between tasks located at different levels in WBS (such links may make sense generally, but the corresponding situations are found in typical planning rather rarely - erratic the arrows from the mixing of automatically linked tasks usually drag along the middle plan everywhere). The extra arrows themselves are harmless, albeit ugly, but turn into a terrible problem when you try to level up the load in volumetric planning.
The problem with torn downloads is actually systemic and makes life difficult for both beginners and experienced Project users. We'll talk about the experienced later, and here we will describe what the typical mistakes are made by the “middle”. These errors are simple - “Middle” often just forgets to see what the resources load in the resulting plan, and as a result this plan violates the rule we mentioned above - “most people work on the full-time project without interruptions”. A characteristic symptom is the boot numbers in resource usage view that are less than or greater than 100%. The problem with overloading (> 100%) is usually solved by applying leveling and advanced midli know how to do it and often recall it (since overallocation is usually visually noticeable on the Gantt chart), but leveling the tasks of some team members usually creates more holes in others . Such a plan gives rise to a lot of practical problems, since it obviously does not describe a realistic project implementation and gives distorted ideas about all the parameters of the project at once - and about the price (which is usually underestimated), and about the actual deadlines for the execution of tasks (which can both be overstated and underestimated) , and about the actual download and resource requirements.
A separate error of the "middle" is a fuzzy distinction between the duration (that is, the absolute time measured in hours) and work (that is, the labor costs measured in man-hours). Here, even advanced MIDLs are lurked by the idiotic Project trap, which is that by default the Duration field is displayed in the grid, and tasks have the default type of fixed units or fixed work and are entered as effort-driven. A typical sign of an experienced "senier" is that he understands these differences and at least enters estimates in the Work field (and ideally changes the default options in his copy of Project and decisively changes the type of all tasks during review and editing).
About the artificial intelligence Project, tormenting the "seniors", we will talk below. In the case of "midles", the nondiscrimination between hours and man-hours leads to a huge number of strange and not always clearly noticeable distortions of the planning parameters at the moment when the author begins to assign resources to tasks.
Another big problem with clocks and man-hours is that, based on practical experience, in their understanding of Project, 90% of clients do not rise above the base level of "middle" and often do not understand which column to look at and what is in this column written by When presenting full planning to Project, characteristic questions from such clients are, for example, “you said that the project will last four weeks, and the total work for some reason you have 560 hours - why are you cheating me?”.
Senior MS Project Designer
"Seniors", i.e. people who have mastered all the necessary features of the Project, and also have a clear understanding of what they want to express with the help of the Project, begin to suffer from the fundamental shortcomings of the Project as a tool and an expressive means.
The problem with tattered loading does not go anywhere and often gets up to its full height even with bona fide MIDL. Part of it is explained by the fact that not everyone clearly remembers the type of task in Project. Part of the reason is the “artificial intelligence” built into Project and which until recently had a tendency to become more and more sophisticated from version to version.
The task of artificial intelligence in the Project is to automatically change some of the parameters of tasks when manually or automatically changing others. A classic example is halving, tripling, etc. the duration of an effort-driven task when assigning a second, third, etc. to it resource The number of scripts of this kind inside Project is quite large. The behavior of the Project in some of them is governed by the settings (some of which are the settings of a specific copy of the Project on a particular machine, and some are saved in the MPP file and transferred between the machines). Not all scenarios and rules are equally well documented, with some settings affecting rather heterogeneous scenarios, etc., etc. In many scenarios, Project behavior seems counterintuitive. In general, this part of the Project is prohibitively complex and it can be stated with a high degree of confidence that the majority of Project users cannot predict all manifestations of artificial intelligence in the course of work and are often not ready for them.
“Midly” most often remain in happy ignorance about the changes that Project makes invisibly for them. The fate of the "seniors" is harder - after a long editing experience in Project of their own, and especially those of others, of large volume, they learn to wait for their tool for sudden filth and periodically check that Project has not spoiled anything in the wake of their changes. The litmus test is the load observed through the resource usage view — unexpected and illogical distortions of the plan made by automatic changes usually manifest themselves as deviations in the level of resource utilization or in terms of the beginning and end of the work of the resource in the project. “Senjor” usually tries to draw planning with observance of simple basic architectural principles (besides uniform continuous loading, it is important that people engaged in related tasks aka in one track start working in a project and are released at the same time) and the deviation from these principles can be seen quite easily in resource usage view.
It is easy to notice the distortion introduced by the system, but it is often quite difficult to correct it, especially in projects of large size or complex structure. Undo often does not help - the manual change that led to the problem rolls back, but the deformity introduced by artificial intelligence remains and has to be corrected separately, risking running into other automatic changes. In certain situations, artificial intelligence becomes stubborn and does not allow to correct the shoals created by it.
Even when editing not the most difficult plans, you need not to forget and not allow the artificial intelligence pranks with fairly simple operations such as transferring tasks from one place to another. Simple, but equally annoying, traps such as auto-link, which we discussed above, even with a simple copy-paste, can create an extra connection between tasks or break the desired one. Some "midley", prone to exploring all the options of a complex system, can include on their machines dangerous and destructive features such as automatic "optimizing" the assignment of resources (meaning it makes sense when planning a Stroybat platoon with shovels) - even if the "seigneur" will inadvertently to review such planning (especially right on the middle machine), the Project will gladly mix resource allocations and create a mess that doesn’t even have a trace of meaning.
But especially unexpectedly, the harmfulness of artificial intelligence manifests itself when editing planning, in which some tasks are already marked as completed, or, to put it more scientifically, tasks in which data on actuals (actual work, actual duration, etc.) appeared. It is in such situations (although not only in them) that artificial intelligence begins to behave especially cynically and make changes in planning that are difficult to tolerate and even harder to roll back. Vivid examples are the sudden creation of gaps in tasks, the distortion of the planned load of resources within a task, the sudden transfer of a task or group of tasks after all others, and the persistent reluctance to insert them back into place, even using manual leveling. An experienced user anticipates such troubles and usually knows some tricks to avoid them (such as disciplined use of task constraints), but in general when working with volumetric planning, especially including actuals, more and more time usually begins to go to fight with the tool, rather than for meaningful editing. At some point, even the “seigneur” gets tired of fighting, gives up, gives up and sighs, sends colleagues or clients a planning in which resources are very often at 83.58% on Friday and 16.42% next Saturday.
As a bonus, we mention quantum effects that occur after several iterations of joint work on a large MPP file (500 tasks), in which a literal colleague decided to fix the beginning of the working day in the calendar from the default 8:00 to something “more appropriate our realities ", like 11:00. A beginner of a “seigneur” who looks over planning, usually on a scale of days or weeks, will be slightly surprised by the strange manner of part of the tasks jumping to the next business day without any visible reason. Looking into the daily resource usage view, he sees in general a completely flat load on each resource, with strange tails, say, 62% in front and 38% in the back. And only by increasing the scale up to the clock, he will be terrified and realizes that if he wants to bring it all into a divine form, an hour or a half of boring handwork awaits him. Usually, the “seigneur” decides not to be a perfectionist (because there are more important things in life than quality planning) and continues to work with what he has. Nudging later on the more sinister manifestations of artificial intelligence, described above, which in combination with low-level burrs on the calendar often look especially strange and are treated particularly tedious.
Continuing the C / C ++ development metaphor (perhaps slightly outdated today), Project’s full-fledged use in complex scripts begins to look like an attempt to build a very large and complex system written in C / C ++ without using make / ant and having libraries for which the correspondence between the header (.h) and binary (.a / .lib and .so / .dll) files at our disposal is not guaranteed. Theoretically, it is possible to do this, but it may require very noticeable efforts and good qualifications, and the assembled system may have critical bugs.
Everything natural is not unremarkable, or Briefly about good.
After discussing the problems and pitfalls of MS Project, the question may arise - why did Microsoft develop and promote such rubbish? We are far from blaming Microsoft for being unprofessional and malicious. Before we continue to discuss the problems, let us briefly touch upon what MS Project is suitable for, and try to explain a number of its features, which at first glance look glaring.
The main idea here will be quite simple and actually coincides with the main thesis of the whole article: MS Project is not well suited for planning and maintaining minimally complex software projects. This does not mean that it is equally inadequate for projects in other areas of human activity. MS Project was created as a universal project management tool - and project management as a management technology is used not only in software development. There are areas of human activity and the scale of projects in which MS Project can be applied without much risk to turn planning into a smoking mountain of tangled pasta. This mainly concerns scenarios where one of the conditions is fulfilled:
- The structure of the project plan (basically we are talking about the structure of the WBS) is either determined by the standards of the relevant field of activity (for example, describes a standard technological process), or at least does not change after the creation of the plan.
- The number of tasks and / or resources is small.
- Tasks are independent of each other, and resources are of the same type and interchangeable.
For a minimally complicated project in the field of software development, none of these conditions is usually fulfilled, although very simple projects may not change in the course of execution and / or contain only about 30–40 tasks and 1–2 executors (in the latter case the truth is that “Heavy” tools like MS Project still raise doubts).
As for those Project features that seem meaningless or even malicious, any person familiar with the history of the software industry should understand that the reason lies in the evolution of MS Project itself as a product - namely, in successive attempts by Microsoft to make it more and more universal, while maintaining backward compatibility with previous versions. The notorious "artificial intelligence" and other features dangerous for beginners are just a consequence:
- the desire to serve with the help of the product as many dissimilar use cases as possible (leading to the complication of the conceptual model of the product and an unsystematic increase in the number of available configuration options);
- the need to maintain the integrity and consistency of this data model during editing; and
- the desire to simplify the study of the product by new users and to make the user interface of the product and the editing process “easy and intuitive”.
Any experienced user can easily provide several similar examples of bloatware, led by everyone's favorite MS Word, which, as you know, 90% of users use only 10% of features. Alas, MS Project, in contrast to MS Word, is intended to describe a certain model of reality - and the excessive complexity in using the tool leads to the fact that the models are inadequate and do not serve their main purpose - they do not allow answering those questions about the project that were listed at the beginning of this article.
At the same time, we recognize that the conceptual model of MS Project really allows us to describe things that are difficult to express right away using popular alternatives (usually based on linear task lists aka backlog-style). The really useful features are of course dependencies - dependencies between tasks, the very same links. ( , ..) .
MS Project
– MS Project , MPP-, MS Project . , , , , Project .
MS Project – - , , . ?
– MS Project . : , - MS Project - .
– , MS Project – - . , , , , , .
, , MS Project « » . , , , , MS Project.
, , « ». , agile, -, MS Project – . , MS Project added value – , ( Kanban board, backlog ..).
, , , , , .
Blissful ignorance
– - . , . , MS Project ( ) . - – , , . (- – « » ). « » , .
reviewer' « X?» «, , Project » « , Project », . « X ?» ( ).
MS Project , , , Project - ( ). Project - , . , MPP- . , , . , baseline - «», - – « ». , , . MPP-, . MPP- , MPP- . .
- , , Project , - , – .
, MS Project. , , , , . , Project .
. , . , , , – , , , .. ( GTD), .
Project - . .
Project , . , Project - .
Project, - ( ) . , - , , Project , .
, , Project, , « ». Project high-level plan, «» MPP- . MPP-, , 10-20 , , «» , , executive summary, . - . (, ) MS Project earned value management (, , ).
, Project . , , , , VCS repository, (, VPN- , -). promotion ( ) , ( ) . DVCS Git Mercurial, « » — . , PMO, «» MS Project, , .
, , , , MS Project Gantt charts. , , Project, Visio .
:
, , MS Project – .
MS Project . MS Project , - , , . - MS Project , , .
, , .
Source: https://habr.com/ru/post/150800/
All Articles