The 5 Secret Jobs of an IT Project Manager

Did you think a Project Manager had just 1 job? There’s a lot more going on behind the scenes than simply “managing a project.”

PMs are often overwhelmed, and always looking for spare time between meetings to get work done. They are pulled in a number of directions, and can easily be distracted from more important tasks. If they’re not careful, they get caught up in politics above them and drama below.

How can a PM stay focused on the most important activities that will best serve their project, organization, and career? By performing these 5 hidden functions:

Continue Reading

PM Pointers: Managing a Team Member Who is Coasting

Part 2 in our 5-part Managing Needy Team Members series.

As project managers, we often run into team members who require a great deal of attention. In an opening post for this series, we discussed a general approach to dealing with resources that need TLC. This post offers techniques for getting the most output from folks who lost interest in work because they expect to exit soon.

Coasters Need TLC, Too

Some project team members know their days of working for the company are counted. Some are coasting towards retirement. Some know their jobs will likely go away when the project is complete. Typically, they just stop trying. Without emotional buy-in, these team members are often more harmful than they are helpful.

Continue Reading

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 PMs 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 to simply 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