Timesheets are boring

Why get passionate about a boring timesheet tool?  They are little more than cells and dropdown choices that collect your time and expenses.  An endless bucket.  Pointless.  Employees reluctantly fill in those monotonous little cells every Friday afternoon or Monday morning for the week prior.  Time tracking is a chore with little value.

Okay, that’s one perspective…

But have you ever viewed them as an investment?  Like pouring value into your organization that you can mine later?  Consider that for a moment.

What if you could magically predict how long your next project would take?  Or cost?  What if you could walk into the next meeting with hard evidence that your company talents are unfocused and distracted?  That you are fighting too on many fronts?  And in too many battles without clear endpoints?  Wouldn’t that be worth documenting your time for.

That’s what time tracking gives you, among other things.  Still see it as a boring chore?

Define: Percent Complete

Percent Complete: The portion of a project task that has been finished.  Calculated by dividing the duration by the actual work.  In most cases, this the portion of the task with timesheet hours actually logged for.

Example: a 200-hour task with 50 hours logged is 25% complete.

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?

Do you like Project Robots?

You just buried your mom and returned from the funeral. You’re a Project Manager on a high profile project for one of the largest tech companies in the world.  It has only been one day since the funeral and you are still raw with emotion.  Now imagine that you get an email informing you that you are not getting a break from the loss of your mom, but in fact, your workload has been increased.  How about a spouse fighting cancer?  Need a little time?  No!  Instead, how about an increased workload?  Sound crazy? Well, imagine no more…these are true stories.  This brings me to an important point.
In talking with a friend of mine with 26+ years of project management experience about Agile vs. Waterfall methods, he said, “You can have all the methods and processes you want but it all comes down to personal relationships and human intervention”.  This gentleman was responsible for one of the largest SAP installations in US history. I was taken aback by the simple answer when he stated another simple cliché, “Take care of your team and your team will take care of you”, which means that they will take care of the project.
The examples given in the beginning of this blog are not meant to say that we shouldn’t be tough or suck it up.  However, besides being in my opinion morally wrong, it is flat bad for business.  Is the man whom just buried his wife still ready to climb that mountain for the team?  Or, is he waiting for the first chance to jump ship?
All too often we pay lip service to our employees, “Let me know if you need any more resources”, while completely ignoring the realities of life.
I guess the bottom line is we can keep on pushing the machine, but what happens when the machine navigator gets ran over?  Does the machine keep going and if so, who is driving…a robot?
Make sure when you ask someone if they need help that you don’t ignore the reality that is staring you right in the face — unless you like robots.

My list of project risks

There are at least a hundred reasons projects fail.  Expect anything from vague requirements to budget shortages to waning passions to unreasonable project schedules.  All novice mistakes…  But we can’t all be experts on every topic.  About the best we can do is identify the most common areas for failure, and discuss these with the team.  At least the team will be aware.

Here’s a quick starter list.  You’ll probably have to make it a little more diplomatic before presenting it to your group.  “:)

1. Newbies don’t know how long things actually take.
2. Unfamiliar technologies need extra research time.
3. Virtual development teams don’t communicate the same as in-house.
4. Team members without a passion for the product won’t perform.
5. Vaguely defined projects either go on forever or burn up in debate.
6. Projects without top-level commitment get lost in the minutia.
7. If the company doesn’t need it bad enough, it will fail.
8. Pick only two: Cost, Quality, or Time.  Let the third fall where it may.

–newshirt

Scrum Burn-down Charts

In the world of project management there are often disputes over Waterfall vs. Agile methodology.  Most people have a bent or preference and there is plenty of discussion whether Agile can fit within any typical Waterfall project.  However there isn’t much disagreement among Agile proponents on the need for a good SCRUM chart.  Check out the link below from a recent blog posted on PMI.org by Bill Krebs.  Bill has an interesting take on Tracking Burn-down Progress…

http://blogs.pmi.org/blog/voices_on_project_management/2011/04/tracking-burn-down-progress.html

Utilization Reports

In a Professional Services company, how do you know if you are billing enough hours to be profitable?  One way is to check to see if you’re still in business.  If so, you’re billing enough hours!

Okay, that works.  But wouldn’t it be nice to tune your billable hours for maximum efficiency?  That’s what a utilization report does for you.  It checks the number of hours for billable vs. non-billable.  the image below is a snapshot of one employee’s rates.  Not bad, huh?

Utilization Report

There’s an unofficial law at our company: Either find a way to bill 50 hours a week, or look for a job elsewhere.

That’s the hard reality at some companies.  You can bet management is watching the utilization reports.  Of course, if they don’t they’ll probably go out of business themselves.

–newshirt

Time estimates are tricky

If you are an inexperienced project manager, engineer, or designer, consider tripling your initial time estimates for projects.  That’s not a slam.  It’s just that new managers don’t take a lot of minutia into consideration when developing project time estimates.  Experienced people have been through a lot of project cycles.  They have seen a lot, and the know the hundreds of little things that can bog a project down or extend it long beyond all normal estimates.  So if you’re new, triple the schedule until you know the details.

7 Things You Need to Know About Development Project Estimations

Whether you are a project manager planning for a smooth implementation of a plan or a project sponsor on whose decisions a project depends, you cannot escape from the fact that project estimation is essential to its success. In the first place, there are three basic requirements that a project must satisfy: schedule, budget, and quality. The need to work within these essential project boundaries poses a huge challenge to everyone in the central management team.

There are various aspects that affect project estimates, such as team skills and experience levels, available technology, use of full-time or part-time resources, project quality management, risks, iteration, development environment, requirements, and most of all, the level of commitment of all project members.

Moreover, project estimations do not need to be too complicated. There are tools, methodologies, and best practices that can help project management teams, from sponsors to project managers, agree on estimates and push development efforts forward. Some of these include the following:

  1. Project estimates must be based on the application’s architecture. Making estimates based on an application’s architecture should give you a clear idea of the length of the entire development project phase. Moreover, an architecture-based estimation provides you a macro-level view of the resources needed to complete the project.
  2. Project estimations should also come from the ground up. All estimates must add up, and estimating the collective efforts of the production teams that work on the application’s modules helps identify the number of in-house and outsourced consultants that you need to hire for the entire project, as well as have a clear idea of the collective man-hours required to code modules or finish all features of the application. Ground-up estimates are provided by project team members and do not necessarily match top-level estimates exactly. In this case, it is best to add a percentage of architecture-based estimates to give room to possible reworks, risks, and other events that may or may not be within the control of the project staff.
  3. Do not forget modular estimates. Once you have a clear idea of the architecture, it becomes easier to identify the modules that make up the entirety of the application. Knowing the nature of these modules should help you identify which can be done in-house or onshore, or by an offshore development team. Moreover, given the location and team composition of each development team that works on a module, it becomes easier to identify the technical and financial resources needed to work on the codes.
  4. Development language matters. Whether the development language is Java, .Net, C++ or any other popular language used by software engineers, team that will be hired for the project must be knowledgeable in it. Some development efforts require higher skills in these languages, while some only need basic functional knowledge, and the levels of specialization in any of these languages have corresponding rates. Most of the time, the chosen development language depends on the chosen platform, and certain platforms run on specialized hardware.
  5. You cannot promise upper management dramatic costs from offshoring. While there are greater savings from having development work done by offshore teams composed of workers whose rates are significantly lower from onshore staff, you must consider communication, knowledge transfer, technical set-up, and software installation costs in your financial estimates. Estimating costs is often more about managing expectations, but as the project matures, it should be clearer whether the money spent on it was money that was spent well.
  6. Project estimation software and tools help identify “what-if” scenarios. Over the years, project managers have devised ways to automate project schedule, framework, cost, and staffing estimates. Some estimation applications also have sample historical data or models based on real-world examples. If your business has a lot in common with the samples in the estimation tool, it can help you identify what-if scenarios and in turn include risks, buffers, and iteration estimates.
  7. Price break-down helps in prioritization. Breaking down the total cost of the project helps management decide which parts of a system should be prioritized, delayed, or even cancel. Estimating costs for a new project may not be easy, but project sponsors and managers must be able to know and agree on the breakdown of costs of development, technical requirements, and overhead.

By ExecutiveBrief -online resource on process management, project management, and process improvement.