Modelling for Success
Categories: Project Leadership
As I begin my personal journey into realestate after earning my associate license, I started reading a book on Real Estate given to me as a gift by my friend, Jeff Hart. I was reminded of a principle that I had been promoting as a project manager or solution architect or agile coach. The keyword is MODELING. I had been espousing this but had not used the word for a while. This is the key to any successful transformation initiative; whether your are implementing scrum or scaledagileframework or projectmanagement or agilemethodology. We should start modeling and achieve certain levels of success based on the base model. Then after gaining some degree of success, we can add our own context and be creative with the adoption. What we do is we get creative early in the adoption process or add creativity on a model that we have not yet fully understood and implemented yet. Thus we risk rolling out the initiative or model ineffectively. Implement the models and have a good and thorough understanding then innovate around them for the purpose of continuousimprovement.
I encountered a good article on the subject written by @Dan McCarthy. In the second paragraph of the article, I read something that resonated to my personal experience. I was about to do a presentation to the CIO and I was told by some of the folks in the organization not to use the acronym ITIL. I was speechless because my talk will be revolving around the value of ITIL if the IT organization adopts the practices to improve the value of IT. Dan's paper quoted this, "Whatever you do, don't mention ITIL". This reminded me of another organization I know who is ramping up their project management resources and I was given a word by one of my friends who consulted with this organization that when I get to speak to their management team, don't use the words "Project Management". I was told to call the practice anything but not project management. There is some semblance to ITIL and Project Management. These two follow a certain protocol or life-cycle in delivering their services to the customer.
Similar to many organizations that tried to implement a project life-cycle or methodology using the PMBOK as a guide, the ITIL framework suffered negative perception. Dan mentioned in his article that ITIL is too bureaucratic, too difficult, too expensive, too complex, too restrictive, slows us down, and most recent one is that it is no longer relevant. This last reason for not adopting ITIL is entirely misleading. Pundits say that ITIL is not longer relevant due to the growth of cloud computing adoption in the SaaS, PaaS, and IaaS space at least. You have heard and read articles written about ITIL being outdated due to the DevOps practices currently in play and all other modern developments in the IT space such as the IoT. As you have read, most of the content I mentioned are all negatives. No one attempts to write the value ITIL gives to the enterprise. No one takes the time to talk about the problems ITIL helps solve. I would encourage you to read the article Dan wrote as he highlighted two areas where ITIL helps solve problems; problems internal to IT and problems in the business domain. Below is a quote of some of problems highlighted by Dan. In my humble opinion, these can be used as critical success factors when rolling out ITIL-based capabilities.
"Internal IT problems:
The above is not the whole list Dan identified in his article. What is compelling is that we can have a crucial conversation with our stakeholders and tell them that ITIL can be a key problem solving feature of the Enterprise.
I recently read an article by @Bill Dow on How To Shutdown a PMO. In as much as I was scared to read the article, I was also curious. I never thought about shutting down a PMO considering that this capability is considered essential to running and operating a business enterprise. I gave it a thought and maybe a worse case scenario would be an enterprise is closing its business. I look at that picture and I said it makes sense. Like a project closure, we need to have a way to close or shutdown every business group using a structure mechanism.
@Bill Dow provided the following as steps to shutting down a PMO:
Like any project, we need to have a schedule for shutting down a PMO. We need to have some way to show progress as this kind of project will typically be under time pressure. Executives would need progress reports and some way to know what remains.
Shutting down a PMO impacts people like any force reduction or reorganization activity. As PMO lead or manager, you need to start working on transitioning the team in the PMO. If the company is keeping other departments active for the future, you may need to give the PMO resources enough time to transition. This is the hardest part and most emotional.
Similar to closing a program or project, the PMO should start reviewing its financial position. This might include paying out outstanding payables or closing out POs. Whatever money left is then returned to the enterprise.
The article talks about other elements that affects a PMO. I encourage you to read the article.
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. Projects 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.
IT Service Management (ITSM) is a set of capabilities that was born from the knowledge and expertise of implementing the principles of delivery value from the Information Technology Infrastructure Library (ITIL) framework. An enterprise that is majorly dependent to its Enterprise IT capabilities continue to acquire technologies that will help it manage I.T. specially when an outage is brought by an incident or a problem. The need for an ITSM tool usually comes out when a software or hardware goes to production use. We call this phase in ITIL Service Operation. Within that phase, we build our Operational Support and Analysis capabilities such as event management, incident management (includes security incidents), problem management, change management, and request management. Most tools that have been produced focused around incident, problem and change management. Many did not take the step to mature and look at all the phases of ITSM and their associated functional capabilities.
Image above courtesy of The ITSM Review.
@Stephen Mann wrote a blog identifying some drivers as to why a new tool is/was needed or the current tool needs to be replaced. He requested the readers to chime in and vote on the identified drivers to help solidify the theory as to reasons ITSM tools are replaced. BTW, he initially listed twenty-five (25) potential drivers. The community help whittle down the list to ten (10). His findings indicated the following:
I highlighted the four (4) drivers that resonated to me as a technology decision-maker. The above high-lighted drivers are the items that a tool should be able to satisfy to enable I.T. to show its value to the business. Having this criteria satisfied will allow I.T. to change the business perspective of I.T.; that it is only a cost center. It can now start claiming that it is also a profit center of the enterprise.
What do you think?