meeting huddle

A Day in the Life of an IT Project Manager

IT project managers cover a lot of ground during the workday. From meetings with their team, business counterparts, stakeholders, and users, to prep work before and after meetings, to sending ad hoc communications as the project demands, PMs are birds in flight.

Let’s follow along a day in the life of a typical project manager to explore what needs to be done, why it’s important for the success of the project, and how to make each task more effective.

Continue Reading

No More Excuses: IT Initiatives Must Deliver Measurable Business Outcomes

Delivering on scope, on time, and on budget aren’t enough. Internal customers want tangible results from IT. They want real value.

But too often, those in charge of IT programs and projects tend to shy away from taking responsibility for delivering actual business outcomes.

In this video, Mikhail debunks the 2 most common myths used as excuses by IT managers for not performing “value tests”:

Excuse #1. IT can’t directly affect business outcomes. (You can and should.)
Excuse #2. Overhead for measuring value is too expensive. (No, it doesn’t.)

Watch to learn how to overcome these lame excuses:

(Did you enjoy the video? Consider subscribing to our YouTube channel.)

TWEETTweet: No More Excuses: IT Initiatives Must Deliver Measurable
Business Outcomes #ITLeadership @MPapov https://ctt.ec/4wz8K+

bird flying free

IT Must Sacrifice Pride of Ownership for Innovation’s Sake

IT often has a complex from being considered a non-strategic business unit, or a necessary evil. In response, many IT professionals try to prove the cynics wrong. They think, “We’ll show them….”, and put a lot of pressure on themselves to come up with game-changing ideas. This overcompensating mindset within IT is counterproductive.

Every time I attend an IT conference I visit technology vendors’ booths. Vendors have gotten really elaborate with their sales techniques. Many offer ROI templates or business case building tools to help IT professionals demonstrate the value of purchasing one product or another. These vendors are enabling the exact behavior that is so self-detrimental.

Let’s admit it: ideas born in IT have little chance of securing participation from the business, let alone budget for developing a prototype. IT-generated innovations don’t get much support because they tend to be technology-based.

Continue Reading

PM Pointers: A “Needy” Team Member Is a Project Risk

A solely results-oriented project manager (PM) sees every project as a personal opportunity to achieve success. On the other hand, some PMs see a project as a series of process steps where their individual role is simply to check boxes.

Neither of these approaches is effective.

To be a great PM, one needs an array of leadership skills. The most critical leadership skill required from project managers is genuine care about the project team members. If you genuinely care about individual contributors you can achieve extraordinary results.

TLC is a natural part of caring about people. Although some team members need more TLC than others.

Continue Reading

runners turning the corner

How to Increase IT Project Team Intensity

Motivation is a concept well-covered in project management resources, and is required constantly for project success.

Intensity is the level of focus by a project team on a particular activity. Without taking deliberate steps, intensity tends to naturally slide. Maximum intensity is not appropriate to maintain at all times, as it could lead to burnout. However, at key points throughout the project you will need to turn the intensity up to its highest level.

The graph below shows a healthy intensity fluctuation over peaks and troughs.

Continue Reading

Shining a Light on Shadow IT

Too often, Shadow IT systems—those not authorized by IT—are used by the business to perform work. Here are a few common examples:

  • A cloud storage system (such as SharePoint) may be authorized and managed by IT, but employees may use external cloud applications (such as Dropbox or Google Drive) when working with external vendors.
  • A collaboration tool (such as Slack or Basecamp) may contain important information and documentation that are effectively invisible to the IT portfolio.
  • Vast spreadsheets may exist across disparate programs, requiring manual reconciliation and long email chains for even the most minor changes.

Continue Reading

5 Risk Tolerance Considerations for Project Managers

How Much Risk You Are Willing to Tolerate?

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.

Continue Reading

CIOs: Never Ask for Money Again

How Do You Fund Your IT Investments?

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.

Continue Reading

3 success factors for fast buy-in

Change Management: 3 Success Factors for Faster Buy-In

TWEETTweet: How does change happen on an #ITProject? Inspiration, Personal Buy-In & Quality #Abraic https://ctt.ec/VjUfd+

IT organizations generally pride themselves on their ability to embrace change. Their project execution methodologies are built around an assumed ability to rapidly identify, respond, and adapt to change.

PMOs establish standardized development lifecycles and a comprehensive governance process for change management.

The Agile framework along with its variations and flavors acknowledge change as a fact of life. Rather than seeing change as a nuisance or a risk to be avoided, agile PM and SDLC models offer a specific methodology and tools to be successful in a shifting environment.

Even traditional waterfall approaches acknowledge the need for controlled governance related to change management. Standardized practices such as Lessons Learned, Post-Mortems, Issue Management, Continuous Improvement, or a formal Change Control process all revolve around the basic concepts for dealing with change:

  • know your current state or expected scenario
  • identify the deviation
  • evaluate the impact
  • define the future state or new scenario
  • make the change
  • analyze the results
  • repeat as necessary

These methodologies provide valuable, step-by-step instructions to practitioners.

But simply following the steps or implementing specific processes does not ensure buy-in throughout the organization. Beyond the methodology and processes, there are less tangible aspects which need to be addressed to produce the desired results.

Dissent is natural. Universal, undisputed acceptance is unlikely. Therefore, don’t expect everyone to just fall in line and be their usual, enthusiastic, productive selves in this new reality. There will surely be a few who push back on the change and are vocal about it.

But it’s a mistake to equate this resistance to not being “a team player.” Getting naysayers on your side will allow you to harness their outspokenness, channel their energy, and create a collaborative environment which will ultimately benefit the endeavour.

Fast buy-in for any endeavor, but especially for technology projects, depends on winning the hearts and minds of those most impacted by the change.

Continue Reading