# σ-driven project management

Hello! Your friendly project management specialist. You may remember me in a blog post such as Why software projects take longer than you think, a blog post I wrote long ago states that the time to complete software projects follows the distribution of a regular log on the σ-driven project.

Slight refresh if you do not want to re-read the post. What does it mean that the project completion time has a standard log distribution? If a project is estimated to take one month to complete, sometimes it takes half a month, sometimes two months. We can describe the “blowup factor” as a real measure compared to the standard. Then assume that the blowup factor logarithm will basically follow the normal distribution. and in particular, the common distribution with zero meaning and the standard deviation σ (which is the Greek word “sigma”).

We can set the standard distribution according to your compressed workload. What does this mean? It means the chances of the project being completed, as a part-time job. See the chart below:

So as an example of how to read this table: if σ = 1.4 and then 84% of the results, you have completed a project within 400% of the initial estimate.

So where does σ come from? My thesis of this blog post is that σ is a natural risk factor for your project portfolio and that different Amanani values ​​validate very different types of project management. Low σ means low uncertainty and means we have to complete projects all the time. Σ High σ means high uncertainty – similar to a research lab – and implies a high risk of a major explosion, which means we have to discard multiple projects.

## The general model is as follows: σ-driven project

The real-time it takes to complete a project has a standard log distribution Every project has the same value if successful 1 Once we start working on a project, we don’t get a response until it suddenly ends At any time, we may choose to (a) continue working on this project and (b) give up Obviously, this is a very dirty model! It may be, down from a rocky outcrop, you can look for just one big diamond. Obtaining a diamond is a “binary” event in the sense that we have received it or not – there is no partial debt, and no “learned” until then. However, if we have been down in one mine looking for a diamond, I don’t know, for ten years, maybe we should re-examine it.

So let’s focus on the decision to finish or leave the project, which is almost there: if something is too late, should it still be worked on? Are you approaching or deviating from success? 2 3

## How much business do you create, my friend?

The amount of business each time is basically a 4 per cent success rate over time spent (i.e., almost, a possible distribution function).

What’s going on here? Working on a project has a growing value for a separate business at the beginning, which makes sense because we are nearing completion. But if we do not complete the task at some point in time, we may be embarking on a “very big” project that will take a lot of time to complete, much longer than we initially thought. So the value of a business starts to decline over time (in high-Aph projects faster). That is, are we still working on something important?

## He pretended to have a low marginal ROI

Most likely, we have selected this project from potential projects, where the top one defeats the 2nd by a small margin. So at some point, if the business value from time to time drops below where it started, we end up in a position where leaving a high ROI project and switching to a reliable second makes sense. That is why it is interesting to compare the current ROI of marginal with the original ROI of marginal.

## The σ-driven project depends on σ

What we have established so far is that high-risk project management means a high percentage of the project left.

This seems to go beyond a bad intelligence check indeed! Any adequate project like research will have a high risk of being blown up. For that reason, we should also be willing to give up a high percentage of these projects. The proper way to manage the planning, resource allocation, and other things is very different:

• Lower management σ
• Low uncertainty
• Almost 100% of all projects are completed
• Very accurate ratings
• Well-predicted milestone lines
• Every day, monitor project completion and make sure it is tracked
• Σ High management σ
• High uncertainty
• Many projects have been cancelled
• Estimates are irrational
• Resources are assigned to powerful ideas
• There will be a lot of sinking costs
• Each day is the first day
• Is the software different?
• I’ve kept it very common so far and you can use it for almost anything – digging for dinosaur remains, or painting a house (student question: which of these is low-σ and which is high-σ?)

But let’s talk about software for a moment. Why is it so difficult to predict? Here is my theory: whatever is predicted suggests that something is irrelevant and should be clarified.

### σ-driven project: Conclusion

If it takes a developer one day to build a single API integration, it will not take them 100 days to build a 100 API integration, because on the 3rd day or so, the developer will create an integration framework for API that allows them to build API integration quickly . . 6 This will reduce the total effort, but the total uncertainty is a little less. Σ – which is a work-related prediction in logarithm terms, will increase.

Generally, this is how we software engineers have been doing it for 50 years now. Everyone’s job at the same time is to build features and tools that make it easy to build features. We end up with layers and shortcuts, and each layer reduces the work we have to spend on the bottom layer. This is obviously good at production! However it does mean that software projects will be difficult to quantify, and many software projects will be abandoned. Datas from erikbern.  So, more blogs will be coming in the Education section.