In Part 1 of Driving Decisions, I talked about my experience as president of our homeowners association and the parallels between being president and being a PM when it comes to driving decisions. I introduced the first five factors to driving decisions:

1. Be clear on what “done” looks like.
   
2. Be specific on who owns driving the decision.
3. Decide who needs to be involved in the decision versus who needs to be consulted or informed.
4. Set the guiding principles.
5. Establish whether you need a best or least-worst alternative.

What follows are the remaining factors to round out the 12:

Read more at ProjectManagement.com.

The waterfall purists typically crave structure, with a clear understanding of scope, schedule and budget before commitment and adherence to scope, schedule and budget through delivery.

The agile purists typically crave nimbleness, with rolling waves of smaller logical work groupings and more frequent delivery. I’ve seen discussions on the topic devolve into shouting matches as to which methodology is the “right” one.

In my experience, project managers generally prefer waterfall while engineers prefer agile. PMI has developed the Disciplined Agile® framework, which sandwiches three hybrid levels between the waterfall and agile anchors.

While I think some of my agile purist friends might take exception to the Disciplined Agile® name (as if agile is an undisciplined framework), the way of working spectrum is a reasonable split-the-wickets acknowledgement that there can be peaceful coexistence between agile and waterfall.

Now I’ve been doing this stuff for four decades, and have seen projects from just about every vantage point performing just about every role in my career. I am actually a fan of a hybrid methodology and have successfully blended components of agile and waterfall in delivering very high-visibility initiatives.

In doing so, I’ve learned and implemented some tips that have helped me drive hybrid initiatives, as follows:

Read more at ProjectManagement.com.

Risks. Assumptions. Issues. Dependencies.

Four concepts that almost every project manager has dealt with in one form or another. When managed effectively, they significantly reduce execution friction and better secure scope, schedule and budget success.

When not managed effectively, it’s like riding a bike with the brakes engaged—you may ultimately get to where you want to be, but it takes a lot more effort to get there.

Key to managing risks, assumptions, issues and dependencies (RAID) effectively is not just understanding each concept—it’s truly internalizing how the concepts interrelate. Understanding the interrelationships better positions the PM to not just manage each individual RAID component, but also to proactively address problems and avert scope, schedule or budget impacts.

To that end, my focus is to not just explain each of the RAID components, but to demonstrate the connection points between them. In my view, which I call the RAID 101 Model, the relationships look as follows:

Read more at ProjectManagement.com

When a PM muddies the water with statements like “everything is critical” to those who truly understand how a project’s critical path works, the PM causes others to question both the PM’s schedule and—more importantly—the PM’s credibility. Understanding the mechanics of critical path is a crucial hard skill that PMs need to master early in their careers.

Before we go further, I’d like to define some basics that affect a project’s critical path...

Read more at ProjectManagement.com

As project managers, we’ve likely been faced with getting a one-line explanation of what a sponsor needs—along with a deadline. Depending on the organization, there could be a range of responses—from doing a back-of-the-envelope calculation, getting people in a room to estimate the work, or using a comparative initiative to assess feasibility.

Now, I’m not here to criticize your organization’s approach, but I have found that having something that enables the PM to rough-cut an initiative using some standards can be helpful in providing a lens on whether a date is even remotely achievable. This is where the work-back timebox model comes in.

Read more at ProjectManagement.com.