PM Dom

Dominic Lepore - IT Project Management

  • Home
  • Blog
    • Archives
  • About Me
Home Archives for Project Management

August 16, 2019 By PM Dom

Supply and Demand

The demand for project resources always exceed the supply of resources. Always. Even at the Department of Defense, with $700B, cannot meet the demand for resources.

The key in success in projects is to manage supply and demand. Most organizations fail. Most fail because they simply don’t know the supply of project resources. Or the demand. Other than that, they’ve got it under control!

Supply

The supply of resources is typically people. Organizations know how many people they have. They may make a crude estimate of person-hours available (number of people X 40 hours, for example). This is wrong. This over-estimates the supply. Your employees do not dedicate 40 hours per week to projects even if they have no operational responsibilities. By the time you subtract staff meetings, time off, HR, and training, it’s closer to 30 hours per week.

The only way to accurately measure supply is to track time. Every employee on a project should track their time. Soon, within months, you’ll have a better number for supply.

Demand

Measuring demand is also beyond most organizations. They don’t do sufficient project planning and therefore don’t know how much time is estimated per project.

The only way to accurately measure demand is to track time. Every employee on a project should track their time. Soon, within months, you’ll have a better number for demand. The best way to estimate time for future projects is measuring time on current projects. Your estimates will continually get better. But only if you track time.

Filed Under: Project Management

September 2, 2014 By PM Dom

Inside the Box Thinking

I have a friend with a company called Outside the Box Consulting. I joke that my company should be called Inside the Box Consulting. I am completely inside the box when it comes to project management. In fact, I strive to be equidistant from every side of the box. The problems with my clients nearly always stem from outside the box thinking. They think there is some magic wand they can wave for project success. Or they believe they are agile even if they don’t know what that means. They seek to avoid the hard work by seeking outside the box solutions. They usually fail.

My advice is straight from research, knowledge and experience. Project management is hard but it is easier if you follow proven methodologies of scope, schedule and budget management. There are no short cuts to success. Leave innovation for the marketing and design people. Stick with science for project management.

Filed Under: Project Management

September 2, 2014 By PM Dom

The Highlander Rule

Project saying #22 – the Highlander Rule:

There can be only one.

The name of this saying is from the cult classic, The Highlander.


I use it when assigning action items on a project. Some people like to avoid action items, or responsibility, or work of any kind. One way they do it is by getting multiple people assigned to a task. If it’s Bob and Suzy on a task, that gives Bob an excuse not to do it. Similarly I don’t assign action items to groups such as IT or Accounting. I want to know exactly who is responsible for the work being done. It does not have to be the person doing the work. It is simply the person I am going to ask for status.

So when someone wants more people added to an action item, sorry ” there can be only one!”

Filed Under: Project Management

September 2, 2014 By PM Dom

Stop it!

Project saying #25:

You can’t start doing something right until you’ve stopped doing it wrong.

As a consultant I am more familiar with dysfunctional IT organizations, ineffective PMOs and failing projects than most people. They wouldn’t call me if everything was ok. I am constantly amazed at how often my clients know they are doing something wrong. It reminds of a famous Bob Newhart skit where he is a psychologist who tells his patients, simply, to “Stop it!” Whatever bad habits or fears they have just “Stop it! Two words, first word S_T_O_P, second word I_T. Stop it.” It really can be that simple.

But I frequently meet resistance. When I see a project not going well and I advise the not-radical idea of clarifying scope, schedule and budget, my clients will complain “can we just let this project go forward?” Umm, no. I say to them:

You can’t start doing something right until you’ve stopped doing it wrong.

Sometimes I also add project saying #19:

The best time to do a task is three weeks ago. The second best time is today.

It is never too late to stop doing things you know are wrong. In fact, it is prerequisite for you to start doing things right.

Filed Under: Project Management

August 7, 2014 By PM Dom

Defining Quality Down

Project saying #66:

We’d rather do 10 projects 60% correct than six projects 100% correct.

I find that most organizations do the former. When I review an organization’s project portfolio a common finding is they are doing too many projects. Some of the projects don’t align with the strategic goals and should be terminated in any case. But even if every project is worthy on its own, collectively they are too much work for the available resources.

Why does this happen? It’s the fault of management (or managers to make it personal). Too many managers feel their sole job is to get more work out of employees. They resort to adding more pressure to employees by adding more work. The hope is the threat, or actuality, of additional work will motivate employees to work harder. As if employees are a clogged drain and the appropriate amount of force will clear the obstacles and allow a lot more work to get done.

Manager’s also hate to have idle employees, so they assign work to meet 40 hours per week. However, project work is variable. If you aim for 40 hours per week, that ends being the floor, not the ceiling. When additional work is required, during design reviews or testing or launches, to name three examples, employees put in far more than 40 hours per week.

When quantity of work soars over 40 hours per week, quality goes down. Quality goes down because employees don’t have enough time to do it right and testing is inadequate to find the poor quality. (Morale also goes down in this situation as Daniel Pink has explained in motivating knowledge workers.) Unfortunately, it is difficult to measure quality in IT projects during the project (and may be difficult to measure after the project is done). And more unfortunately, many IT project managers are not technical so they would not be able to determine quality in the first place.

Since measuring quality is not an easy thing to do, management reverts to measuring quantity. Perhaps they can measure quantity of requirements, lines of code or user stories accomplished but usually it’s quantity of hours – all too easy to measure and usable by the lazy and unsophisticated. This results in a situation described by 37 Signals founders Jason Fried and David Hansson:

some people “try to fix problems by throwing sheer hours at them…. This results in inelegant solutions.” Workaholics “aren’t heroes,” they write. “They don’t save the day, they just use it up. The real hero is already home because she figured out a faster way to get things done.”

Measuring true performance and developing a culture of quality is hard. So most organizations don’t do it. But they have to compensate for their culture of defining quality down, which leads us to the corollary of the saying at the start of this post:

We’d rather do 10 things 60% correct than six things 100% correct. Then we define 60% as an A.

Organizations that have a culture of only rewarding more have to come up with a new definition of quality. Voila!

Don’t fall into this trap. Do more by doing less. Terminate the least valuable projects and dedicate more resources to the most valuable. Both morale and quality will rise when employees have enough time to do things right.

Filed Under: Project Management

August 5, 2014 By PM Dom

Presenting at the 2014 PMI Global Congress

SM_Badge_block_PresentingI’ll be presenting Lessons Learned from the U.S. Health Benefit Exchange Projects at the 2014 PMI Global Congress in Phoenix, October 26-28. It’s a summary of the analyses I have done on the state efforts to implement the Affordable Care Act. Collectively, billions of dollars were spent. Even small states such as Maryland and Oregon managed to spend over $100M on failed implementations. Oregon eventually abandoned their effort and will join the federal exchange. Maryland also abandoned their effort and opted to spend another $50M to buy software from Connecticut.

I cataloged the biggest failures here.

Filed Under: Project Management

May 2, 2014 By PM Dom

Metrics to Improve Project Performance

I love Kaplan and Norton’s balanced scorecard concept and I have designed and implemented it several times for my clients. It calls for balancing traditional financial metrics such as cash flow and ROI with three additional dimensions: internal business processes (which I call operations), customers and learning and growth (which I call HR).

If your operations are projects (aerospace and defense, consulting and construction companies among others), then your metrics in internal business processes should be project-based metrics. I’ve developed a list of metrics that companies should use to monitor and improve project performance.

MetricDescription
Schedule PerformanceEarned value metric (SPI) or % overrun for completed projects
Cost PerformanceEarned value metric (CPI) or % overrun for completed projects
Scope% scope delivered (by features, deliverables, stories or requirements)
Resource Utilization% of workable hours (typically 2,000 per year) spent on projects
QualityNumber of bugs or defects
Change RequestsNumber of change requests
Change Request Approvals% of change requests that were approved
Schedule Estimation AccuracyComparison of planned vs. actual by task type (coding, testing, etc.) and by person
Schedule RiskQualitative assessment of the risk to the go-live date
Scope RiskQualitative assessment of the risk of the day 1 feature set not meeting client's expectations
High RisksNumber of high risks
Risk MitigationNumber of high risks that are "accepted"
Critical IssuesNumber of open critical issues
Overdue Issue ResolutionNumber of critical issues not resolved by their due date
Staffing PlanNumber or % of planned project positions that are filled
Contingency BalanceBalance of contingency funds still available
Deliverables PerformanceNumber submitted on time or late, the number of days late, the number accepted or rejected
Training% of people trained
Customer SatisfactionCustomer and stakeholder satisfaction as determined by survey

Filed Under: Project Management

April 23, 2014 By PM Dom

One Way to Understand Agile Methodologies

I describe the difference between the traditional waterfall methodology with an Agile methodology as the difference of going vertical vs. going horizontal. You can see this in the difference between the two pictures below.

The first picture represents the typical waterfall project schedule. You essentially do all the planning, then all the design, then all the coding, then all testing and then you implement. This is not exactly right – there is usually overlap between the phases (hence waterfall) but this is more or less accurate. I call this “going vertical.”

Agile Example 2

 

 

 

 

This next picture is how the same project would be done using an Agile methodology. You would take Feature 1 and plan, design, code, test, and, maybe, implement before moving to Feature 2. I call this “going horizontal.”

Agile Example 1

 

 

 

 

It’s easy to see the advantages of each technique. Agile (going horizontal) enables you to go through all phases early in a project. You discover coding or testing issues on the first go-around so you can improve each iteration. But the downside with Agile is you may discover something while designing Feature 4 that forces you to re-write early functionality. So you increase the probability of re-work but you lower risk of discovering issues late in the schedule..

In the traditional waterfall methodology (“going vertical”), you rarely have to re-design something because you have taken everything into account during the (one) design phase. Of course the issue with waterfall is you don’t discover coding or testing problems until late in the project schedule – maybe too late.

When appropriate, I use Agile since it lowers the risk of a project. However, Agile is not appropriate for many types of projects or in some companies and the majority of projects are still managed using a waterfall methodology.

Filed Under: Project Management

April 22, 2014 By PM Dom

Most Active Project Managers on Twitter

Using Scraperwiki, I analyzed the top project management tweeters for a month (March 15-April 14, 2014). I gathered tweets using the #pmot hashtag. Other hashtags such as #pm, #projectmanagement and #pmi are common but #pmot seems to be the standard for Project Management Online Tweets.

The overall stats for this 31-day period:

  • 10,288 tweets in total
  • 330 tweets per day on average
  • 1,585 distinct Twitter screen names

The highest number of tweets, by far, was from @PMVault with 2,285 tweets, nearly 1,700 more than the second most. However, @PMVault just tweets job postings so it is useless for most PMs. I eliminated it from the rest of the analysis.

The rest of the top 10 looks like this:

Top PM Tweets

Tweet NameTweetsFollowersPerson
ProjManagers4225309
ProjDirectors3705022
ARRAPM301931Allen Ruddock
AllThingsPMO213458Alison Murray
humanwareonline202304
BarryHodge173822Barry Hodge
PM4TM1291084Cesar Abeid
pmoplanet1291761Ralf Finchett
cobaltpm1177879
thePMObox11393000Bernardo Tirado

Additional information is in this table:

Tweet NameWesbiteContent
ProjManagershttp://projectmanagers.org/Blog articles by volunteers
ProjDirectorshttp://projectdirectors.org/Blog articles by volunteers
ARRAPMhttp://www.arra-pm.com/Blog articles
AllThingsPMOEvery day stuff
humanwareonlinehttp://www.humanware.it/Blog articles (in Italian)
BarryHodgehttp://projectnewstoday.com/Blog articles from many sites
PM4TMhttp://pmforthemasses.com/Podcasts
pmoplanethttp://www.pmoplanet.com/Blog articles, aggregated articles on PM
cobaltpmhttp://cobaltpm.com/Blog articles
thePMOboxhttp://paper.li/thepmoboxAggregated articles (not on PM), podcasts, his book

Filed Under: Project Management, Research

April 17, 2014 By PM Dom

If Your PM Works 50-60 Hours Per Week, Then They are Doing It Wrong

Many of the PMs that I talk to tell me that they are so, so busy – averaging 50-60 hours per week or more. To be provocative, I say “You must be a really bad project manager.” My point being is that if you are unable to manage your own time effectively, why should you be trusted to manage other people’s time?

To be sure, many people exaggerate the number of hours they work. Averaging 60 hours per week of work is damn hard. I suspect people include their commute in that number. And some confuse at work with work. But I’m sure some people really work 60 hours per week. And that means they are doing it wrong.

My main point is above – why are you so bad at managing your time? I’m positive you did not schedule yourself for 60 hours per week – probably 40 hours (or slightly less) like everyone else on the project. So if you’re scheduled for 40 hours and work 60 that means your estimates are off by 50%! And more shocking is that estimates for how long it takes you to do something are going to better than estimates for the other team members. So your entire schedule is going to be off by more than 50%. Interestingly, the average schedule overrun is 60% (according to the Standish Group).

Assuming your PM is working 60 hours per week, I am concerned that they are either doing menial tasks or the quality of the work is low. Research proves that the quality of work goes down the more hours that are worked. This is common sense – we make more mistakes at 9pm than we do at 9am. Now, if a PM is doing menial tasks (you know what I’m talking about – PowerPoint slides, tweaking Microsoft Project just one more time, etc.), the decrease in quality may not occur or be noticeable. But that is also concerning. As a PM, I work on the hard things – the risks and issues that require concentrated effort and innovative thinking. I can’t be effective if I’m doing this at midnight – my solutions will not be elegant or functional. If your PM can consistently work 60 hours per week with no noticeable decrease in quality then they aren’t focused on the right things.

In any particular year, I work unplanned overtime just a few times per year. (Note the word unplanned – because some IT project work must be done on weekends, I plan to work several weekends per year.) If I see a PM working a large number of hours, it’s a red flag to me.

If your PM is consistently working 60 hours per week then they are doing it wrong.

Filed Under: Project Management

  • 1
  • 2
  • Next Page »

Twitter

Tweets by @DominicLepore

Recent Posts

  • It’s Not Micromanagement
  • Benefits Realization
  • Why PMP?
  • Active Learning in the Classroom
  • How Not to Design a System

© Copyright 2014 Terrapin Consulting LLC · All Rights Reserved · Powered by WordPress &middot