Project Tasks and Issues Tracking

You identify the scope and nature of a project. Design the project plan and assign resources and begin the process of real work and plan executions. Many tasks follow a predicted path and glide down the slope toward completion. Others hit speed bumps and issues arise. If you only encounter a few issues along the way, they are fairly easy to manage with emails and spreadsheets. The issues still require special attention and follow up costing time and energy, but manageable. What happens if you 130 issues arise in a short period of time (as is often the case in software development and bug fixes)? Spreadsheets and emails won’t cut it. In no time you lose track of events, issues and milestones. I am pointing out the obvious. But I have counseled hundreds of project managers using outdated tools and methods to track issues. Maybe project management and issue tracking software/tools cost a little money (others cost a lot of money), but believe me, they will pay for themselves many times over in saved projects, efficiency and ultimately the bottom line.

Seven Days in Utopia

The movie Seven Days in Utopia is clearly not up to Robert Duvall’s standards.  The story points were awkward and difficult to decipher.  One-shot git-er-done scenes and Karate Kid theme didn’t help.  But I managed to scrape out the movie’s arc and purpose.  It’s about faith and trust in God… and a little golf thrown in.

Buried in the poor directing was a principle that resonated with me.  Duvall’s character says, “The game of golf is about conviction.”  He continues with, “Watch out for that random idea that comes at you, that will throw you right out of your game.  Without conviction, it will make you question your game and shake your confidence.  Without confidence, you cannot win.”

It occurred to me that project management is exactly like that.  Without a clear strategy that rests on bedrock conviction, random ideas from so-called experts will shake your confidence.  You’ll chase a dozen “great ideas” from outsiders and never execute your strategy.  Although while that’s true, you must still remain open to new input.  It’s a touchy game.

Moral of the story: Develop a solid project strategy and hold your confidence.  Follow through with confidence.

Why Foundational Features Matter

Let’s say you know customers need a really complex feature, but your project team only has time for a basic implementation.  Do you wait until you have team resources to build the full implementation?  Or do you just build a basic foundational product that doesn’t actually meet any current customer requiments?

My answer: Start with the basics.  Add later.

Foundational product features are usually enough to sell the full implementation.  Customers can see that you have a percentage of what they need.  That helps them have faith in a full implementation at a later time.  They know it’s just a derivative of your current implementation.  But without something tangible to demonstrate, they won’t believe you’ll do the feature at all.

Phased Product Releases

What do you do when you find yourself in the middle of a deep product feature hole?  I’m talking about developing a new feature that you find is taking four times as long as you originally thought it would.

For project managers like me, panic sets in…

Here’s why: Having the product readily releasable is the absolute highest priority.  Deep dives jeopardize that.

So here’s what I’m going to do for this particular feature.  Reluctantly, I’m going to release it over four product releases.  Here’s how I’ll phase it out:

        1. Database plumbing (already released two weeks ago)
        2. Middleware, or business logic plumbing (next week)
        3. Basic feature functionality (a while later)
        4. Full feature functionality (a bit later yet)


Trust Me, I’m a P.M.

An often overlooked step in the project management team is the project/client representative. The person responsible for being the messenger, intermediary between the project team and the client is a critical role. Larger companies pay professionals to strictly fill this role, while smaller companies often let the PM handle that role. This is fine in most cases, unless your PM is not good at customer relations. Customer relations’ professionals spend their entire day thinking of how to build trust, gain confidence, and maintain a relationship. Project managers spend their day doing this on some level within their project team, but it is not their main focus. If you are good at customer relations it will make the project run smoother because the client will have a certain level of trust. If you are not, the project becomes hindered. Why? Because, the client doesn’t have a needed level of trust in you, they begin to question your work. Now the client wants more status meetings. Maybe the client begins to micromanage your project and requires more of the project manager’s time and attention? This can quickly snowball because of one misunderstood statement that breaks a fragile trust. Whoever is communicating with the client, make sure it isn’t General Patton. While he gets the job done, in the project world he would make the job more difficult.

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?

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  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: 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?

Define: Material resource

Material resource: A non-human, quantifyable substance assigned to project tasks.

Material resources are assigned to project tasks, but are not human resources.  They are any quantifyable material used to complete the task.  The image below illustrates.  In this example, 40 yards of sod are used in completing the “Lay sod” task.


Earned Value Increases As It Travels

Earned value (or the value you receive on your intellectual property) increases as it travels through the supply chain.  In other words, the farther an item travels from the manufacturer to the consumer, the more value it brings the manufacturer.  Consumer items change hands many times before they end up in consumer’s hands.  Each time they change hands, more money is invested, and therefore the value goes up.

Consider the illustration below.  A single egg isn’t worth much until it is developed.  Its value rises 100 times from nest to table.

Have you ever considered that software does the same thing?  It earns value as it passes from idea to developer, to QA, to packaging, to reseller, and finally to consumer.  So, the true Earned Value of a product is dependent upon its position in the supply chain, not just at the coder’s keyboard.  You account for such value by quantifying your products on their route to the consumer.