U.S. Losing Competitive Edge in Technology

The recent eWeek story regarding U.S. decline in science and technology (see below) is nothing new.  We’ve heard this same story for twenty years.  But is anyone listening?

http://www.eweek.com/c/a/IT-Infrastructure/US-Losing-Competitive-Edge-in-Technology-Science-National-Science-Board-610257/

Over the Christmas break, I did my bit to encourage passion in software development, engineering, and project management.  I mentored a college student with an Arduio board.  (See http://www.arduino.cc/)  The Arduino is a microcontroller with inputs and outputs for controlling external devices.  It’s big in university engineering departments.  Awesome, dude!

We stayed up past midnight wiring circuits and slinging C++ code to exercise the Arduino I/O ports.  In a rat’s nest of wires, LED’s flashed, speakers squealed, and relays clattered.  Cool!  When it was over, the kid had a new passion for product development and engineering principles.

Code ‘til you drop, and then do it again tomorrow!  That’s my answer to declining technology in the U.S.  And I suppose it’s also my preferred project management style.

Groupthink…Project Killer

Susan Cain just wrote a piece in the NY Times talking about the destructive force of groupthink (article found here: http://www.nytimes.com/2012/01/15/opinion/sunday/the-rise-of-the-new-groupthink.html?pagewanted=all). This started me thinking how groupthink applies to project management and the synergy created or hampered within a project team.
After reading the article I am more convinced that as a project manager it is important to encourage and draw out people’s experience and opinions. It is imperative that project teams have a voice and strong leadership to maintain project goals while remaining open to the team voices. Otherwise, we have the inverse problem. Instead of shortsighted groupthink that has little innovation and a blind rudder. You get analysis paralysis where the goal is clear but the wheels just spin. Which is worse? Probably about the same…nothing gets done, or it does, but it is completely wrong and misses the mark. What do you think?

Ever Have One of Those Meetings?

I was in an important meeting and the project team pretty much knew that a certain person wasn’t carrying their weight. This person wasn’t a complete let down…but could do more. During the course of our project meeting an issue was raised as to why a task had not been completed. This person became defensive and started pointing fingers and making excuses. I lost it. A normally mild manner person, I let him have it. I gave him the what for and how come. However, I was out of line and spent hours in one on one meetings apologizing to this person and the rest of the team. There is a time to kick someone in the pants and a way to do it. My way that day was wrong. It costs our team more time in apologizing then this person not completing their task. The bottom line is we have to play the game with the team that we have. There isn’t always time to replace someone and many times there isn’t anyone else available…period. My advice…if you aren’t getting the job done, own it and move on. People respect that more than excuses. Secondly, be slow to speak or you may make a situation worse. I know, because I did

Negotiating and Managing Project Expectations

One of the many factors in project cost overruns is due to setting unreasonable expectations. Whether working as a consultant outside a company or as a project manager within a company, all too often we become “yes” men to secure a deal or please superiors. We may win in the short term by getting the job or by delaying management’s wrath by telling them what they want to hear, but, in the long run, both scenarios are losers. As a consultant you land the gig and wind up with bad word of mouth advertising as being late and over budget. As an internal project manager you develop a reputation of being unreliable and/or overly optimistic. Instead, be real and upfront about duration and costs of expected projects. Give pushback to help set reasonable expectations. Maybe someone else will promise the moon? You should challenge competitors’ unreasonable assertions. You may still wind up losing the deal, but in the long run you will maintain your reputation and eventually land more deals because of it. Short term pain for long term gain is tough in this economy. What is your word worth and where do you go to get your reputation back?

Daily Scrum in 1910?

Warren mentions Henry Gantt’s desire to update project schedules daily (see post of Dec 27, 2011 http://www.projectteamblog.com/?p=190).  He met with his team daily!  I find that refreshingly visionary.  Gantt is seeing a hundred years into the future, and doing things the right way.  He’s staying on top of things in his own 19th Century way.

Sure, Gantt’s daily meetings were not the same as a Daily Scrum meeting — Scrum is not a warmed-over Gantt chart.  Gantt was simply reminding his team of the project schedule and tasks ahead, and updating his new-style chart to reflect the conditions on the ground.

That effort alone — the daily meeting — probably accounts for 75% of the success of any project.  Three cheers for Henry Gantt — 1861-1919!

 

–newshirt

The Gantt Chart and Daily Project Coordination

All project managers have used or at least heard of a Gantt chart. The Gantt chart was created by Henry Gantt around 1910 and still widely used today. It was used in major projects like the Hoover Dam. Henry Gantt designed the Gantt chart to help manage project scheduling and work progress. If you read his book, Work, Wages, and Profits (1916), you will note that Gantt believed it was imperative to communicate daily schedules to key players and by not doing so rendered schedules useless. Gantt thought it was important to be a project coordinator, to coordinate activities, and reduce conflicts. I think this is an important and often overlooked part of being a project manager. We often look at the larger picture and fail to identify “Daily” influences that cause project slowdowns. We should have daily expectations and identify barriers to those expectations each and every day.

Reference:
Gantt, H. L. (1916). Work, wages, and profits. San Diego, California: University of California Libraries.

Predictive Analytics

Predictive analysis uses historical records to predict future trends or outcomes.  That got me thinking; could that be applied to timesheet records?  The most common field for predictive analysis is credit reporting, where lenders hope to predict a buyer’s ability to pay.

Do you have a 900 credit score?  Me neither…

So, back to timesheet data…  What could we possibly learn from predictive analysis of timesheet records?  Here are some possibilities:

  1. Cost and duration of certain projects in your portfolio
  2. Employee contributions to strategic projects
  3. Typical project contribution histogram overlaid on today’s projects

–newshirt

Project Documents

A project manager has many things to administer…time, scope and cost, to name a few. These items are always considered in the very basics of project planning. It’s second nature.

What about managing all the various documents involved with project planning? Some software will accommodate document management, while many others do not.

It is important to have critical documents available to key resources, or all resources. Standard Time allows you to attach files to tasks. This makes related documents easy to locate and available for viewing when necessary. Many document management companies utilize Standard Time for their time tracking and project management. When considering project planning, make sure you have a solid software system that will help you be more efficient with document management.

Why is it called ‘Waterfall?’

Warren has been expounding on project management methodologies lately, so I figured I’d throw in with him.  Consider this explanation of the ‘Waterfall project management model.’  It might be useful to some.

Here goes…

Why is the old project management model named ‘Waterfall?”  What, exactly, does that mean?

I believe the term stems from the notion that water falling over a dam is hard to scoop back up to the top.  Virtually impossible, one might argue.  The term ‘herding cats’ comes to mind.

So how does that apply to project management?

In real life, some projects are like that.  Not all, but some.  Consider building a skyscraper, for example.  You absolutely have to get that foundation right the first time, because you cannot go back and work on it after the ironworkers have laid a million tons of infrastructure on top of it.  In other words, reworking the foundation would be as hard as scooping up water that has already fallen over the Hoover Dam.
But are all projects like that?  How about software?

No.

Software is malleable.  You can work on any part at any time, even after the product ships.  So the Waterfall model doesn’t apply as neatly.  Or at all.  But it’s still applicable to certain projects where it’s hard to rework ‘foundational’ stages.

–newshirt

Projects…Time…Projects…No Time

Talk with many PM’s around the world and, no matter the project or project type, properly allocating time and resources is a never ending critical part of the job. Estimates based on the most solid metrics are subject to change and cost overruns. So goes the life of a project manager.
 
What’s surprising is how many PM’s don’t take advantage of the software tools available to them and deployed in their environment. Sure, most PM’s use the resource assignments, task dependencies and many of the software features available, but many do not put the simplest of task items into the software’s calculations such as the estimated task start and end dates.
 
I have seen tons of project plans that include the basics…task hierarchy, resource assignments, and maybe…the tasks start date. Why not use the tasks due/end date too? It takes a few extra seconds to enter and will help better identify resource overload and task delays. Standard Time has a resource allocation chart (pictured below).
 
 
 
 
Standard Time also displays the inverse, Resource Availability (also shown below).
 
 
 
 
I know a good number of PM’s utilize these tools properly, it’s to their advantage. But, many do not. I have seen it a hundred times. Aside from the obvious project idiosyncrasies, why not take a few seconds and save hundreds of minutes?