I have been a practitioner of project management for a while. I was attracted to it because of the opportunity to work with smart and intelligent people that creates a product and delivers value to the organization. Often times, I would encounter organizations whose perspective of project management is simply having a list of tasks that need to be done by a mandated timeline. I have questioned this work model in every conversation I will have with folks. I thought is this project management or simply just being a task master. I believe it does not take a lot to be a task master specially when you use the power of coercion to get a job done.
I have tried my best in my practice to start any project I am involve with identifying the scope of work that makes up the product and estimating time. Often times, I will get an order that says I need this project done by a specific date. I would ask my stakeholder what is the business driver for this. I will ask who is our sponsor so that we can manage the work and manage expectations properly specially when the driving constraint is schedule. Many a times, I would see projects executing as soon as the executives said get this job done by this time. I still have to meet an executive who will stay rational when push comes to shove. Project driven by this kind of pressure usually under perform. It is a hidden cost to the project that is not highlighted. No ones pays attention to the process of estimating work to manage and mitigate schedule risks. Most of the time you will see a PM under pressure who would start building a project schedule by himself with no or little project analysis and definition.
What do we normally do when we miss a “promised” delivery period? I would assume many can come up with various reasons in and out of the project team’s circle. I probably would say start with a strong leadership and a determined goal of improving the culture of “just do it”. Project stakeholders and sponsors should be made aware and hopefully get them to emphasize the value of accurate estimates. Our estimates should improve one project after the other and management/leadership should reward such improvements.
One thing that I have promoted is the PM fundamental of creating a work breakdown structure (WBS). I don’t see any project team that does this work anymore. However, this is one of the ways we can improve our estimates; by creating a WBS. The WBS helps visualize work packages or backlogs that will make up the product the project should deliver that gives value to the business and meets the customer needs. The WBS enables us to define work better and properly I hope.
What should be the next step in the cycle when you choose to practice the creation of WBS in your projects. I think you need to have the project team members involve in identifying the work package items and let them provide the estimates. This is a another fundamental PM practice. The project team members knows their availability and the work that needs to be done. Therefore they are in the best position to provide an accurate estimate and a not guestimate if it is only one person creating that project schedule and putting estimates himself. Estimates are estimates and should be treated as such. Project managers and executives should be honest to the stakeholders when the estimates have to change. Again this is in the interest of managing expectation and mitigating project conflicts.
You have heard how the agile techniques have help projects deliver faster. I say this is not different in project estimating. BTW, you need to have a method for estimating. In agile, they use planning poker. I would again go back to another PM fundamental in estimating which is the 3-point estimating technique in case you don’t have a way to use analogous estimating method.
More importantly, always account for schedule risks specially those driven by the unknown unknowns. You need to create contingencies both in your schedule and budget. This is also your opportunity to validate assumptions to help you better understand project risks.
BTW, have a method of tracking effort and progress. Your team will be loaded with work that would distract them from doing project work. It is important that you have a mechanism to identify potential timeline issues before the schedule gets impacted. I use the earned schedule method on plan-driven projects. In agile methods, I use the backlog, release and sprint planning to understand project performance through either the burn up or down charts.
In the end, you need to have a method of ensuring that you can meet the schedule goal at the minimum and deliver value as early as possible to the business.
Now this is a good short take on DevOps. It indeed a recipe.
There have been some great posts recently regarding the difficulting in defining DevOps e.g https://www.jumpcloud.com/what-is-devops-blog/ and following on from that http://www.scriptrock.com/blog/the-problem-with-defining-devops.
My view is that some of the confusion, and the multiplicity of opinions about what DevOps is, comes about because people are using the wrong cognitive frame when looking at DevOps, and maybe a bit of re-framing is in order.
Firstly, a bit of background. In The Blind Watchmaker (1986, pp. 295-296) Richard Dawkins explains that DNA is like a recipe, not a blueprint. You can’t take a slice of cake and then pull up the “cake engineering blueprint” and point to the section that specifies that part of the cake (as opposed to comparing a car or plane part to a blueprint, for example). You have a recipe… but there isn’t a one-to-one correspondence between the recipe and the cake.
“A recipe in a cookery book is not…
View original post 318 more words