Agile is about empowering teams and individuals. The roles defined by Agile are: Product Owner, Scrum Master, and team member. Not listed? Project sponsor.
That said, organizations often have established practices around designating a sponsor or two when a project or program is initiated. How do these two worlds meet? Should Agile teams have sponsors or not? Can a sponsor provide value to an Agile project?
Read More
Many organizations try to fight against project failure by adding budget, resources, or time to the baseline. However, throwing money at the situation often leads to wasted efforts and more frustration, if the root problem isn’t addressed. Failure itself isn’t necessarily something to resist (see our thoughts on failing fast). However, pulling the plug on a major project can be easier said than done. Internal politics or other factors may limit the team’s ability to admit failure and cancel an initiative.
When your project is destined to fail, but abandoning ship is not an option, a brief pause and shift can allow you to turn things around before you completely blow the budget.
Read More
Sure, we all want our IT initiatives to succeed. We regularly evaluate our projects, in-flight or upon completion, looking for tangible lessons to learn. We apply these strategic and tactical takeaways in hopes of increasing the chances of success for each subsequent initiative. We seek approaches that work for different industries, organizations, teams, and technologies.
But looking back at the many IT projects I’ve been a part of in my career, I can’t help but notice a common theme associated with success: people who genuinely care tend to find a way to get it done.
Read More
Change is HARD. As a matter of fact, I often say “technology is easy, but people are hard.” You can guess the reaction I get from technology-focused individuals when I make this statement. For an organization to grow, be successful, compete, and embrace technology and new processes, change is required.
There are many excuses given for why IT fails to focus on driving change in their organization and across the enterprise? Here are just a few:
Yes, change is hard and often overlooked by IT organizations. But it is required for technology and process adoption and therefore requires dedication in the form of a champion.
Change without a champion is likely to fail.
Read More
Every project manager deals with risk assessment and risk management. If done right, the project manager will ensure the overall project plan includes a risk management plan early in the project. The risk management plan is typically guided by the risk attitude of the project stakeholders, which is determined by their risk appetite, risk tolerance, and risk threshold.
The PMBOK Guide offers detailed definitions and guidance for each of these factors. For this discussion, we will use simplified descriptions:
Risk appetite is the level of risk that an organization is willing to accept to reach its goals and objectives. Risk appetite is typically culturally determined within the organization.
Risk tolerance tells you how sensitive the organization or the project stakeholders are to risks, their willingness to accept or avoid risk. Risk tolerance is variable, if not fluid, from person to person.
Risk threshold is the level of impact, typically a clear figure, beyond which the organization will no longer tolerate the risk. Risk threshold is a negotiated or determined quantified limit.
Project stakeholders are hardly ever asked what their individual tolerance level is. They agree on the risk management plan, but transfer their trust and expectations to the project manager. Stakeholders may understand the risk, but they may not fully grasp what acceptance of the risk means in practice.
Read More
First of all, if you are an IT manager or executive and have asked for money to fund a project, you are brave. Too many folks in IT are order-takers. So, hats off to those valiant IT leaders who create business cases for IT initiatives, and present justifications for investments.
However, there is an inherent issue with “asking for money.” It’s as uncomfortable for the asker as it is for the askee. It is almost like you are asking to borrow money with a promise to repay with interest if everything works out.
What’s worse, a pattern of asking for money widens the gap between the business and IT. It doesn’t need to be like this.
Read More
The User Acceptance Test (UAT) is a critical component of any IT implementation. The goal of a UAT is to validate if a system or solution will meet the needs of business users in their operational environment.
The outcome of this phase sends the project down one of two paths. If all goes well, the project moves on to the Go Live phase. If it’s a flop, the project faces many challenges ahead, the Go Live timeframe is at risk, and the credibility of the project with the business may be tarnished. Obviously, the stakeholders want the UAT to go well. So how do you secure a win?
Let’s explore the 10 key ingredients of a successful UAT. We’ve seen this recipe work across a wide variety of IT projects.
Read More
A health check is a formal examination assessing if an IT project is on track and under control, and serving as a valuable continuous improvement tool. The outcome is a project health report that proactively and impartially informs project stakeholders of the well-being of the initiative.
Too often, a project health check is only initiated once a project already is in trouble. But best-in-class organizations require health checks at several points during a project’s life cycle.
Creating the health report can be time-consuming, and it is typically not the responsibility of the project manager (PM). Instead, such reports should be produced by an independent party for the benefit of the project sponsor. I’ve seen health checks carried out effectively by a central Project Management Office, an internal auditor, or an external 3rd party.
Read More
“This implementation is going nowhere fast and I am canceling it,” said the CIO.
I was in shock. In an IT career spanning decades I had never witnessed an executive make a decision as bold as this. But, truth be told, this particular implementation had already gone on for twice the allotted time and delivered nothing notable—beyond a very long list of open issues.
Still, I jumped in to defend the struggling project. I said we would be foolish to waste all the efforts made to date. I said the business case had a clear ROI. I said reputations, and possibly jobs, were on the line if the initiative was terminated.
Read More
An IT department’s most critical point of failure lies in its inability to cancel a dead-end project. Canceling a project can be a great move, but it is uncommon. (When was the last time you canceled an IT project?) All too often, IT departments waste significant time and money on a fruitless effort.
Let’s explore the major reasons why an IT project reaches an impasse. Knowing the reasons will help find an effective, yet low-risk path to fail fast and move forward.
Read More
