Posted on

Define: Timephased

Timephased: Total project task hours distributed over a period of time.

An example from Microsoft Project of this is shown below.  The hours for each project task are distributed over the duration of each task.  The hours per day is the ‘Work’ field divided by ‘Duration’ field.  In other words, the total work is spread evenly over the duration.  Choose the Microsoft Project views below to see these task layouts.

 

Tracking Gantt View:
 

 

Task Usage View:
 

You can see that the 100 hours are timephased over 10 days for the first task, and over 1 day on the second task.

Posted on

Great Product Features Have Solid Business Case

For our company, great features rarely come from high-octane project brainstorming sessions where the heavens open to reveal the glory of God.  Instead, they come from lowly customers here on earth.

Here’s how it happens:

A customer calls up and says, “Why is your product so lame?  Why doesn’t it do such-and-such?”

“That’s none of your business!” cries an eavesdropping passerby.

Oops, no.  Not the correct response.  Instead I ask, “How would you like it to work?”

Nine times out of ten that question turns into a great new feature.  We discuss the business case and work out an alteration that fits the common usage much better.  Customer is happy; we’re happy.  Now we just need to sell it to the executive management and development team.
Why is this exchange so valuable?  Because it comes from an actual customer with little vested interest in the product.  They just want it to work better so they can get their work done faster.

BINGO!!!

That’s the key.  Anytime you can reduce admin time or improve product usage, everyone wins.  Nobody likes a hard product.  Dreaming up great new features in a boardroom rarely accomplishes those basic goals.  Talking to customers is where it comes from.

Problem is, who’s talking to customers?  Tech support, sales, and maybe a marketing hopeful willing to mingle with the great unwashed.  These are the lowlife employees nobody listens to.  So how does the customer need get filtered up the channel to executives and then back down to the development team?

Give them a database.  Let them submit feedback from the trenches.  If they can articulate the business need clearly and effectively, people will listen.  The best features always come from customers.

Posted on

The Common Error in Estimating Projects

I recently read an article on the PMI website about bad estimates and project cost overruns. The article was by Dr. .James T. Brown. Dr. Brown talks briefly about the typical political and personal pressures that cause failed estimates. However, one of the more interesting items listed in the article is recent Oxford Review on Economic Policy. The review studies infrastructure estimates and has a comparative graph showing road/bridge type projects vs. IT projects. Guess which one is more commonly underestimated? Here is a link to the article… http://www.pmi.org/en/Knowledge-Center/What-Causes-Bad-Estimates.aspx

Posted on

MS Project Overallocation

Assigning a project resource to a task by percentage alleviates the problem of overallocation.  Below are two project tasks assigned to the same time period.  If they both must be completed, you have an over-allocation problem.  Over-allocation simply means that the person has been assigned too much work to perform in a given time period.  In all likelihood, they will not be able to complete the work.

 

 

Choose View, Resource Graph in MS Project to see the problem  Red bars mean the resource is overallocated for that time period.  In this case, there is double the work that is reasonably expected from the project team member.  So how do you fix that?

 

 

Here’s how to solve it:  Assign the resource to work only 50% of their hours on each task.  Assigning project team members a certain percentage of their hours reflects the likely situation on the ground.  Hald their time goes to one task and half to the other.  Let the resource figure out when to actually perform the work.

 

 

This is the new resulting project resource allocation graph.  It shows that the resource is fully allocated to 100%.

�

Posted on

Reach out to new kids

I remember my first software development job in 1992.  I joined a software company that developed for the “new” Windows operating system: Windows 3.0.

As a junior member of the team, I was deathly afraid of revealing what I didn’t know and lose my coveted new job.  I was sure everyone on the team knew more than I.  So worked 72 hour weeks to catch up.  I studied, and coded, and watched, and listened, and tried to fit in as best I could.  It worked perfectly!  But it turned out I wasn’t the only newbie, and I learned that I knew more than I thought.

So now as a project manager, I’m sympathetic to newbies.  No newbie will lose his job just because he hasn’t been immersed in the latest technologies.  Reach out to the “new kids!”

Posted on

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.

Posted on

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.

Posted on

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.

Posted on

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)

–newshirt

Posted on

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.