Project Management

Taking the Plunge

by
In case you actually read this description, the beginning of the blog is about preparing for the PMP exam. It then evolved into maintaining my credential. After taking a break for a few years, I'm back and will be blogging about project management, in general, and probably a bit of agile on a regular basis.

About this Blog

RSS

Recent Posts

What's in Your Project Management Tool Belt?

Scale Your Product Owners

When is a Good Idea a Bad Idea?

Is it a Project or Maintenance?

Do You Deliver Product or Value?

Optimism and Vacuums

Categories: Project Management

I thought I'd take a moment and think about something other than election coverage.

I'm not sure if it's cause, effect, or altogether something else, but optimism and vacuums seem to go hand in hand.  Think about your last project, for a moment. How accurate were the estimates given in the early stages of the project? If you have even a little experience in project management, you knew they weren't going to be accurate, but you may not have identified all of the reasons why.

The obvious reason is that the earlier it is in a project, the less you know about the project.  A factor that often gets overlooked is everything else going on in your organization.  You can know that it will take six months to complete the project... if that's all anybody did.  How long will it take when you account for everything else going on?  Planning projects in a vacuum happens all too often, and it results in optimism about how much work an organization can complete in a given amount of time.

We're all familiar with the concepts of effort and duration, I hope.  If you want to know when a task can be completed, you need to know how many hours it will take for the assignee to complete the work, but you don't stop there.  Next, you need to determine how many days it will take for the assignee to find the time to perform the work. I'm sure I'm not the only project manager who has seen a task that only required two hours of effort take more than two days to complete, for legitimate reasons.

Tasks are to individuals like projects are to organizations. There can be unknowns that make it difficult to estimate the "organizational effort" of a project. All project managers deal with this. We also need to understand the "organizational duration” of our project, taking into account the other projects and activities (priorities) our organization is pursuing that could affect our schedule.

If you think that this is starting to sound like portfolio management, you might be right. If your company is effectively managing a portfolio of projects, instead of running multiple silos of projects that, surprisingly overlap, you are doing better than many other companies.  This is the vacuum and optimism I'm talking about. When we plan our projects in a vacuum, our estimates are basically blindly optimistic.

What can we do about this situation?

Don't run out and buy portfolio management software. Throwing a tool at a problem, without at least minimal analysis, just creates another way to fail.  There are three aspects of problem solving that need to be addressed, in order. They are:

1) people

2) processes

3) tools

You won't solve the problems associated with optimism and vacuum-based estimates without the right people.  You might be able to deal with this approach internally, but don't ignore the value of a third party facilitator or coach to help guide the change. 

As you're getting the right people involved, make sure you all agree on the problem that you are trying to solve, then start identifying gaps in your current processes. From there, you can identify any additional processes and tools you may need.

Simple, right? Okay, maybe not as simple as I make it sound.  You may not need a robust portfolio management system. Alternatively, you may need one, but not be in a position to implement one.  Your mission, should you choose to accept it, is to gather the right people and figure out the best way for your organization to break away from optimism and vacuums.

Posted on: November 08, 2016 11:16 PM | Permalink | Comments (5)

Priorities

Categories: Project Management

When everything is a priority, nothing is a priority.

I've been saying that for over a decade and had no idea it was an actual quote, by Simon Fulleringer.  I'm not claiming it was me.  I just thought it was one of those things that was inherently true and often overlooked.  It's also a sign that priorities probably need to be addressed.  That is where I find myself.

I've been trying to do too many things for a while, now, and not gotten very far on any of them.  The impact to my blog is that I am going to start posting every two weeks, instead of weekly.  As I will also be cutting back on other activities and using my time more effectively, or trying to, anyway, this should give me time to finish one of the books I've been planning to post on  - The Agility Shift. 

My plan is to post more content about making an agile transformation, not just about adopting agile practices.  I'll also post about some of the personal projects I am working on, and will continue to give updates on my agile team, at work.  And, of course, anything else project management related that comes to mind.

Speaking of my team, we had our first formal retrospective, today.  One of the things that was identified was how valuable the communications tools we are using have been.  We've got developers in three different countries, but they are in regular contact with each other in spite of time differences.

The team is all on the same page with regards to improving our definition of ready.  We're going to make a conscious effort to examine our stories and determine when more detail is needed in the story before putting it into the sprint, and when we just need the appropriate conversations to take place.  There needs to be enough detail to estimate the work without BDUF - big design up front.  The conversation is key.

Back to priorities.  It's not that you're not important, but I have other priorities that I need to take care of tonight.  See ya' in a couple of weeks!

Posted on: October 24, 2016 10:30 PM | Permalink | Comments (6)

What Assumptions Do You Make About Projects?

Categories: Project Management

We've all heard the old maxim about what happens to you and me when assumptions are made.  Sometimes it's true, and the point is always valid - check your assumptions.  If you have even a few years work experience, however, you probably know that checking all your assumptions, before you are expected to act, isn't always feasible.

Assumptions are made all the time, in business.  They range from how someone will perform or act, to pricing and demand for a product, to what people know and need to know, to how processes are performed, and lots of places in between.  Even when best efforts are made to turn assumptions into inferences into something closely resembling facts, we still get it wrong, sometimes.  No matter how good our research is, we are still predicting outcomes and have the potential to have missed or misinterpreted one or more variables; we are still at risk of failure.

How does this apply to projects?  Have you ever assumed that requirements were complete and accurate, or that somebody's work was finished and bug-free?  I hope not, but assumptions can plague projects, if not dealt with appropriately, which is why requirements and risk management are such an important part of project management.  Even if your requirements are exact and you have mitigated or transferred all identified risk, a project can still have setbacks or fail.  Some of these sources of failure are due to assumptions made before the project has even started.

  • Is this the right product for the company portfolio?
  • Will there be demand for the product?
  • Is the company prepared to sustainably deliver the product?
  • Do you have, or can you get, the right people for the project?

I'm sure there's more.  Since this is a blog about project management, I'm going to let smarter people than me deal with the first three items.  The last item, however, touches on a topic I mentioned in a previous post.  The assumptions we, as project managers, make about the people on the project directly affect the success of our project.  We often assume:

  • They know how to do their job
  • They provide honest and accurate estimates for what it will take to complete the work
  • They understand how to effectively participate in a project

…and the list goes on.  So what can you do? 

You probably can't teach them how to do their job.  You're a project manager and may not know how to do their job.  You can help them with estimating their work, but you're limited if you don't understand their work.  You aren't likely to be able to teach one person the PMBOK, let alone the entire team, before you start a project.  But you can walk the entire team through the project approach at the beginning of a project, without causing significant delays.  By making this part of the project plan, you get everyone somewhere close to being on the same page, and give the team the opportunity to ask questions about what is expected of them.

I describe the (waterfall) project approach as follows:

  • The definition of Done - how the user/customer experience will be different when the project is complete - include project deliverables, but the user/customer experience is the focus
  • The phases of the project
  • Phase gates for the project - how we will know we are ready to progress from one phase to the next
  • The types of testing that will be needed/performed
  • Stakeholders and project roles (RACI charts as needed)
  • Meetings, communication, and status reporting - include frequency and owners
  • Tools & Processes - requirements elicitation & management, task tracking, test automation, communication, change management, etc…

It would be great if you can have all of this put together in the beginning of the project, but that is not always possible.  You rarely have complete details at the beginning of the project, even if your projects are rolling out the same products to different customers.  When explaining the project approach, you may also have to explain how the missing pieces will be identified and who needs to help fill in the gaps.  You won't have all of the answers, yourself; knowing who can get you the information you need is one of the keys to success as a project manager.

All of the things that I describe in the project approach are things that we, as project managers, do.  What I am saying is that we need to share this information with others, and not assume that they know how the project will be run, which will help to reduce assumptions that they make about the project and what is expected of them.

There, you have my thoughts on project assumptions.  What assumptions do you make about your projects?

Free PDUs - The People and Projects Podcast:

http://www.peopleandprojectspodcast.com/index.php/resources-for-project-managers/earn-30-free-pdus.html

Posted on: June 12, 2016 08:10 PM | Permalink | Comments (1)
ADVERTISEMENTS

"Talk low, talk slow, and don't say too much."

- John Wayne