Project Managers There Is A Better Use For Those Long Work Hours
We all love it when we have staff who work around the clock. Makes life easier, doesn’t it? I’m not so sure.
If we are working 16 hour days, what is that doing for anyone? For the company, we may be cutting our salary in half and saving them from hiring another person. In some cases, I’ve noticed that others didn’t work as long because someone else was always willing to work through the night. That was nice of us. Did that make the project run better? Isn’t it fun to manage people and related emergencies at two in the morning?
Think about it. If the extra time we or our team puts in is just doing the same things we would be doing during the normal day then all we are doing is, maybe, saving the company or project money at the expense of our personal time (assuming our staff works on a fixed salary, no overtime pay). Let me instead illustrate the missed opportunities when using this approach.
A colleague asked me how I was able to get others to use my ideas. He said he had all sorts of ideas and suggested them all the time, but no one ever picked up on them or otherwise used them. I said, OK, describe the idea to me, which he did. I then asked him how well the idea was working for him.
He looked confused. He said that no one was using his idea, so he didn’t know how well it worked, but he just knew it would work well. I asked him why he was not using it. He said he didn’t have the time. He had his own work to do and he was regularly working late and the weekends to get it all done.
Great, we are working around the clock to just get the normal job done, everyday. This goes back to the notion above about how wonderful it is that we are saving the company money. We might be getting a bit more ourselves, since we work so long and hard, but we are probably not getting twice the salary as the next guy who doesn’t work that long. Gee, maybe we are hoping to get a promotion?
I’ve worked long hours all my career. I loved the work. What did I do in those long hours, late into the night and the weekend? Did I just work on getting my normal job done? No way. I was usually working on something I noticed or wanted to try out. It might have been learning something new about the programming language or system I was working with or crunching some numbers from a data system I hacked into in trying to understand how my project was really going. Rarely, if ever, did I work long hours to just do more on whatever my assigned tasks were.
In some cases, when I had an assigned task, I would finish it very quickly, possibly working long hours. I would get it done, now, even though I might have a few days before it was due. I would then develop a method to pull the data and generate the needed information or report automatically if it was management related. If it was programming related, I might go in and try to solve the same problem several different ways — usually based upon other ideas that had come to me as I fixed or completed whatever I was assigned to do. This is where I spent my long evening and weekend hours. Doing something extra. Exploring something or someplace I’ve not been before.
From these late night and weekend explorations I would come away with knowing more than I knew before and/or having developed a capability to do the work I just did in a fraction of the time I had completed the original work. When I was inevitably asked to do it again or to modify something or to do something similar, I could do it in just about no time flat with very high quality.
Did I then turn in the work, minutes later, for tasks that should have taken hours or days? Sometimes I did, but that almost always seemed to confuse people. It also set an expectation that whatever I did must have been easy as few people knew of the hours or evenings I had spent developing the capability or insight. Instead, being able to quickly and accurately finish my work just left me free time to do more exploration, learn more and develop more capabilities. The point here is that if we are working long hours, I recommend we spent some of that time increasing our ability to do a good job, and not just getting the daily routine job done (and that includes the routine emergencies!).
When I had developed some of these capabilities and folks noticed me using them, they had a tendency to say “hey, can I get that?” Some, seeing my ideas (automated tools, reports, etc.) went off and developed their own. One individual came back, showing me an automated reporting system he developed for his department based upon what I had done, and was very excited about what he had accomplished. He had some good ideas that I in turned borrowed and added to my own processes. This particular reporting method was later integrated into how we did all our reporting (it was related to defect reporting and tracking) and just became the way we did business. This is where I would then hear “hey Bruce, how do you get people to use your ideas ….” Clearly, I didn’t say “hey, how about doing this?” and everyone then jumped on the bandwagon and started doing it. Instead, it came from developing and trying out a technique or methodology and then once it was working well, being able to help others use or adopt or develop their own capabilities (gee, kind of like being a consultant!).
From my experience, if we are just working long hours to get the normal job done, then we are squandering those long hours. Instead, use those extra hours to learn or develop or improve what we are doing. Plan the project schedule so that it can be accomplished using reasonable work weeks. We then have the overtime for handling the occasional need to fix a particularly nasty problem or, better in my experience, to innovate and learn and find better ways to do our business (or even a new business line). At least in my experience in the high tech field, our staff are more than motivated to do these kind of things. Just don’t waste the motivation and encourage continued mediocrity by planning for everyone to work long hours and through the weekends as a regular project management tool. It is not worth the apparent savings and we reduce our opportunity to innovate and improve and hence our ability to stay in business (and keep a job) for the long term.
Do your or your project management teams regularly work long hours just to get the normal job done?
5 thoughts on “Project Managers There Is A Better Use For Those Long Work Hours”
Comments are closed.
Comments from around the web:
Mark Wilson • The “badge of honor” of working all night or weekends that is seen as normal in some corporate cultures is counter productive from what I have seen. In training project managers in multiple fields over 20+ years, Bruce’s concept of planning for reasonably normal hours and devoting time to sharpening skills is a better approach for productivity, quality and retention of talent. In our experience there is often 15 – 40% greater productivity in teams where we have trained at least the key people in the communication, collaboration and attitude management skills needed to advance projects. All the planning and tracking tools in the world won’t trump effective communication and buy – in.
Bruce Benson • Noureddine,
Unfortunately, or fortunately, many people have adapted to these kind of work hours. I don’t think they are really more productive, rather they’ve paced themselves while spreading it out over longer hours. I once dropped in on my boss around 5 pm who was with a couple of other more senior managers. They happily chatted about all sorts of things for about 2 hours and then my boss happen to say “well, I there are a few things I need to do so I’ve got to get back to it.” This 2 hour break at about this time was normal for them. They simply worked and lived at work.
Mark,
Yes. The trick we used was to leverage their natural interest and motivation. Most people were in these jobs because they wanted to do this kind of work. When I would also periodically talk to my managers and leads about communications, interpersonal challenges, motivation, etc., they almost always improved in dealing with these issues. I had one fellow PM once, when I started a spontaneous discussion on dealing with the typical politics that went on “around here” tell me “thanks, this is they kind of stuff I’ve wanted to learn more about.” Regular training and refreshers on what appear to be common topics is amazingly useful.
Good feedback.
Bruce
More comments from elsewhere:
Richard Jouault • Couldn’t agree more. In my experience, what was once a valuable resource only called upon in extreme situations (round the clock commitment by staff) has now become almost standard and any employee who appears to offer less than the perceived “normal working hours” which is 120% of your employment contract requirement is frowned upon or a source of gossip in the lunch room.
Bruce Benson • Richard,
The other side of this experience (e.g., 120% of contract) is the effective reduction in salary. Especially for engineers, scientists, computer programmers, system administrators, etc., their salaries can look high based upon a median national salary, but once the *normal* hours are counted, they no longer look so high.
At one company I asked the Project Director what kind of hours his folks were working. He acted uncomfortable and quickly said “they can work a lot more!” They were working 40 hour weeks but had a large project, a new product launch, that they were looking to start. Clearly, longer hours was his expectation.
Bruce
More comments from elsewhere:
Noureddine Harche • I would agree that the project schedule should not include week end hours as a rule. What do you consider “normal hours” ( per week)? .
Bruce Benson • Noureddine – Good question.
…
I’ve never actually seen any project use more than a 40 hour week, even when we regularly worked around the clock and on weekends. The problem of course is that this has a built in productivity multiplier assumption of something like 150% — so we do 1.5 hours of work for every planned hour of work!
For organizations that do this, I generally estimate schedules using a top down approach (ie, how long has it taken in the past to do a project like this, see: http://pmtoolsthatwork.com/get-schedule-right/) as the normal bottom up approach — calculate tasks and resources to produce an estimate — is too unrealistic.
Bruce
Some of the more interesting comments left on LinkedIn:
Ashish Datta • Bruce, I think you touched the favourite topic of all PMs 🙂 My view has been that the timeliness of a project being recognized (higher up the level than the PM himself) is the usual culprit of long hours. The PM generally inherits a tight timelined objective and is screwed up from the start. The resulting gaps in the quality of deliverables or the ‘bugs’ left for operations staff to handle(that get the deliverables from the project to take forward), are seen at most as ‘irritants’. The loss of value, or suboptimal return from the project, is rarely owned up by the higher-up (who’ve usually cashed in on the publicity already :-). so, I’d call it a organizational maturity thing than a isolated PM issue if a seasoned PM is executing the project.
David MacLeod • Bruce – what do you consider to be a ‘reasonable work week’? For the purposes of planning, the productivity expectation should be openly declared … yet when I discuss with my PM students how many productive hours are included in an ‘effort day’, most have no idea what I’m talking about!
Ashish – excellent point; I agree with you that the source of the problem is a lack of organisational maturity.
Regards, David
Bruce Benson • Ashish – I agree, most issues are not isolated PM issues, but organizational issues the PM must manage within their project. (I write often on tight timelines, such as: http://pmtoolsthatwork.com/compressed-project-management-schedules-discourage-innovation/)
David – Agreed. I recall in one organization using something like 67% on a 8 hour day (we tried to measure these things, see: http://pmtoolsthatwork.com/one-great-way-of-using-your-project-management-staff-hours/ ). The COO was unhappy with the resulting estimate, so she *suddenly* recalled that she had *just* “talked to an industry colleague a few days ago” and 90% was a better number! So we had a couple of issue to contend with: 1) what was the actual average productive hours for estimating, and 2) Senior executives that were not looking for accuracy but numbers that supported the tight timelines they had already promised!
Great topic.
Bruce