How To: Use Master Projects

This post will discuss the simplicity of using master projects in MS Project.  The image below shows a master project with two subprojects under it.  Three MS Project MPP files are required to create the project below.  The master project file is independant of the individual subproject files.  Follow the steps below to create a master project with subprojects.  Notice the green icons next to Sub1 and Sub2.  They indicate the sub-files included in the main master mpp file.

 


Master project and two subprojects

 

To create a master project in MS Project:

  1. Create a new MS Project file named Sub1.mpp (see the example above)
  2. Add some tasks
  3. Create another mpp file named Sub2.cpp
  4. Add some tasks to it
  5. Create a third mpp file to act as the master project
  6. Click in the first row of the master project
  7. Choose Insert, Project…
  8. Choose Sub1.mpp
  9. Repeat steps 6 – 8 for the second subproject (the results should be similar to the image above)

 

–ray

Define: Resource Utilization

Resource Utilization: Percentage of hours actually worked, when compared with possible working hours.

 

Formulas:
    Utilization = ActualWork / TotalHours
    EffectiveRate = ActualAmount / TotalHours

 

Standard Time® contains a resource utilization report that looks similar the to image below.  Notice the ‘Scheduled Hours’ value, and the ‘Actual Hours’ under it.  These number are used in the formula above to arrive at the ‘Utilization Percentage’ of 103.8%.  This person obviously worked an extra 1.5 hours.

The effective billing rate is related to these numbers as well.  In this case, the person worked on some high-value projects at caused his effective billing rate to be higher than normal.  That’s a good thing!

 

 

–ray

Fortune Favors the Brave

Something in Bill Gate’s interview has been hanging with me (see quote below).  I suppose he always says this, whether they are making risky bets or not.  And I suppose Microsoft can make risky bets all the time.  They can afford to.

We’re making sure we take some risky bets.

 

What’s hanging with me is the effect that ricky moves have on small companies.  The first thing to understand is that risk produces reward, just like the Roman poet Virgil said in 19 BC.  “Fortune favors the brave.”  That’s nice to know.  Its a special promise, just for the brave.  Not for the weak and fearful.

But that fortune can take years to realize.  What do you do in the meantime?  After all, you don’t just get brave on isolated occasions, and magically watch the fortunes roll in.  You must stay brave all the time.  So that’s the second thing you should know.  Staying brave is harder than it looks – a lot less glamorous than one might imagine.  And it’s boring.

Yes, boring.  You slog along through thick and thin, excersing your braveness along the way.  Nobody is watching.  Nobody applauding.  You just fight for your vision, and hope you were right.  Only time will tell.

But how do you inject bravado into your project team?  How do you energize them to fight when everyone else says give up?  The answer is simple: be a bright light in a dark world.  People will naturally follow.  No coersion is necessary, just a strong, clear vision.

 

–ray

Telecommuting: Got Motivation?

Over half (51%) of CIOs and top leaders dislike telecommuting.  See the CIO Insight article below.  If I were asked, I’d favor it… but only under certain circumstances.

http://blogs.cioinsight.com/parallax_view/content/workplace/most_employers_resist_telecommuting_1.html

 

I’ve telecommuted for the past 15 years, and it has worked great for me.  My next-door neighbor, Dean, is an IT manager, and he works from home three days a week.  With a 100-mile RT commute, that’s no surprise.  Personally, I wouldn’t work fifty miles from my work unless they paid me a lot of money!

But telecommuting doesn’t work for everybody.  Unfortunately, a lot of people suffer from a lack of self-motivation.  I personally don’t, except at about 4 PM on Friday afternoons.  Working from home can be a lonely proposition, especially if your family is away, or if you have no family.  What keeps the motor running?  Why work?  You have to be personally vested in your project team’s success.  You have to love it so much you’ll split rails to get your work done.  In our affluent society, that’s not normally the case.

Another problem: project teams can’t easily meet.  Yes, there’s telephone, email, and GotoMeeting, but are you using those tools?  Does your team meet regularly?  And if so, are you just a laptop screen on a conference room table?  Where’s the group dynamic?

I favor telecommuting when there are solid, measureable heads-down project goals, or when employees are financially vested in the project.

 

–ray

Build vs. Buy

Every company needs specialty tools to make their company run – little things to help make things easier.  For example, a cabinet shop might need custom-built jigs.  An auto mechanic may build a few of his own tools for jobs he performs frequently.  High-tech companies certainly build plenty of in-house programs to manage information technology – databases, data entry, customer records, etc.

The question I’m posing is this: when is it right to build those custom tools in-house, or when should you go out and buy a suitable tool instead?  For instance, should an auto mechanic build his own 500 piece wrench set, or go down to Sears and buy them?  Should a tech company build a time tracking product from scratch, or license something like Standard Time®?

Since I’ve personally worked in consulting for a number of years (in another life), I’ve seen it all.  I’ve seen companies build products that were available off-the-shelf for 1/100th of the cost.  And, I’ve seen people shoehorn freeware code and products into commercial use.  Both were mistakes.

I tend to say that companies should only build products that are much more expensive to buy.  In other words, don’t try to write your own compiler – Microsoft does that just fine.  Another reason to build is when you have exotic business needs.  One last reason might be if you have time on your hands.  If you’re not making money serving customers, maybe you’ll have time to write and maintain a few necessary tools.  But that’s a dangerous position to be in.

In IT, we ignore such advice because we know we can build everything.  But I suppose the mechanic with a little metal-working and welding experience does the same thing.  🙂

What tools have you built, and regretted it?  Post a comment and let me know!

 

–ray

Define: Actual Work

Actual Work: Hours collected in a timesheet or with a timer indicating the total project hours an employee has actually worked.

 

Collecting actual work in a product like Standard Time® in important.  It allows you to compare your original forecasts with the actual hours worked by employees.  This can lead to some valuable metrics, including percent complete and estimation variance.

Assuming your original estimates are close, percent complete will tell you how far along the project is.  This is obviously more valuable to project managers and executives who are slightly distanced from the day to day tasks.  In some cases this can be their only indicator of the project status.

Refining your estimations can also be valuable, especially if your company performs the same projects over and over again.  Only actual work can give you exact numbers, and that can lead to more profits.

–ray

The Long Product Pipeline

Ever wonder why there are so few product-based companies, and so many service-based ones?  It’s all about cash flow.  The images below illustrate this, but they need some explanation.

Product-based companies
If you’ve got bright ideas of building a product and making lots of money, think again…  There’s a long pipeline from product development to big piles of sweaty cash.  First, you have to build the product.  Nobody’s paying you to do that.  It’s your nickel, pal.  And you can spend as much time as you like.  But then comes marketing and promotion.  Get it out there for the world to see – but still more time without pay.  And then, when they find your product, you’ve got to sell it and collect your reward.  It can take months or years.  And it can be exhausting.  See the stages below.

 

 

Service-based companies
Want cash quick?  That’s why there are many more service-based companies in the world.  In that model, you can find a client and begin invoicing them after the first thirty days.  The path to that stack of sweaty cash is much shorter.  But, the stacks are smaller.  And, you tend to live on them so they never accumulate.  Lose a client, and you’ll have to start over.  Even this model has it’s risks.

 

 

 

So which model suits you?  Got the time of invest and wait for the “big” payoff?  Or, do you prefer earning as you go along?  There are plenty of advantages to both, and only you can decide what’s right for you.  Hopefully, this short post will help in your decision-making process.

 

–newshirt

Define: Technical Debt

Technical debt: Engineering changes you owe a project before it can be signed off as completed.  E.g. software, electrical, mechanical, ergonomic, and other engineering issues to be resolved.   If you’re tracking bugs, enhancements, defects, and other project issues, then you no doubt have some technical debt.  In other words, your team owes the project something before it can be said to be complete.  Every one of those issues should be documented, fixed, and verified by an objective party before project completion. Engineers, and in fact everyone, tend to sweep little things under the rug.  Especially when they don’t know how to resolve them.  Can’t fix that annoying little bug?  Easy answer: don’t tell anyone.  That’s just human nature.  Hide your deficiencies.  Make yourself look good.  Ignore the hard things. A good project team culture faces up to difficult little deficiencies.  A simple line item in a bug tracking tool like Standard Issue® makes them public, and that resolves most of the “facing up to them” issues.  Now everyone knows they exist, and must eventually be dealt with.   –ray

90 Days is Never Enough

If I give you 90 days to complete a project, but don’t hand you a checklist, chances are the project won’t be completed.  A project without clear deliverables is a green light to surf the web all day.  It doesn’t have the teeth to get anything concrete done, and leaves you without direction.  Given such a project, most people will simply say, “I’ll do what I can,” and then do almost nothing.  I’ve seen it happen.

 

Measurable goals
Consider making your goals measurable in some way.  Find a way to boil them down to simple numbers.  Example: this new feature will let us process 1,500 new transactions per day.  Or, the new system will let 1,000 new customers to submit service requests.  Don’t just say, “make it better.”  Make it measurable instead.

Make it quick
Giving arbitrary timeframes like 90 or 180 days without milestones is foolish.  Some people will believe they have all the time in the world, and wait until the night before to start.  Remember cramming?  That’s the mode most many people work in.  Instead, tighten in the deliverable dates, and let the project go late, if necessary.  That tends to keep people on task.

Make it simple
Don’t try to boil the ocean.  It never works.  Simple, foundational projects work best.  If they are completed to your satisfaction, you can build upon them later.

Now you can roll your eyes (like I do) when you hear, “it’ll be finished in 90 days.”

–ray

How To: Add Progress Lines in MS Project

Progress lines in Microsoft Project help see where tasks are behind schedule.  They’re hideous to look at, but serve a useful purpose.  This post shows how to add progress lines to a Microsoft Project file.  Buckle up; this may get rough.  🙂

 

Start by adding a few tasks to a new project:

  1. Add Task 1, with 10 hours duration
  2. Add Task 2, with 20 hours
  3. Add Task 3, with 30 hours

The tasks and Gantt bar should look like this.  At this point, we have no progress lines, just simple task bars in the Gantt chart.

 

 

Add a Project Status date:

  1. Choose Project, Project Information
  2. Enter a ‘Status date’ for when you would like to check task status (the status date progress line will be red)
  3. Click OK

 

Add progress lines:

  1. Choose Tools, Tracking, Progress Lines
  2. Click ‘Always display current progress line’
  3. Click ‘At project status date’
  4. Click ‘Display selected progress lines’
  5. Click in the list and choose the dropdown arrow
  6. Select a date for a progress line (these lines will be black)
  7. Click OK

You should now have two progress lines on your Gantt chart, and things may have gotten a little ugly.  As you move the task bars, the progress lines will update.  Tasks before the progress line will cause the line to go leftward (that’s the ugly part).  What good are they?  Backward facing lines are those tasks you need to move forward.  They need to be rearranged to meet your current project plan.  The image below is an example.  Notice how the lines go backwards to tasks that are behind schedule.

 

 

–ray