Posted on

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

Posted on

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

Posted on

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

Posted on

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

Posted on

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

Posted on

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

Posted on

Sleeping on the Job

Sleep happens!  Especially on Mondays…  I recently read that 35% of all respondents to a recent polls admitted to napping on the job.  If I would have taken the poll, what do you think I would have said?

Of course I have!  And the other 65% have too, but they won’t admit it.  I’m not sawing logs all day long, but yes, it happens.

The MSN article below claims we’re sleeping about 2-3 hours less than those before the invention of the electric light bulb.  Duhh.  That’s no surprise.  Every invention has its unintended consequences.

http://health.msn.com/health-topics/articlepage.aspx?cp-documentid=100205002>1=31036

I really feel this has an effect on our projects.  I remember burning the midnight oil during the dot com, while attempting to start a new software company.  I literally worked two back-to-back 8-hour days.  And fought to stay awake every day.

Most people don’t go to that extreme, but they do watch their shows, surf the web, and play video games late into the night.  All because of the humble electric lightbulb.  🙂

 

–ray

Posted on

Define: Work Variance

Work Variance: Difference between the current ‘Work’ value and the baseline ‘Work’ value for a task .  In Microsoft Project, this is a read-only column.

 

There are a lot of variance fields in Microsoft Project, and they all relate to baselines.  Baselines are a way to compare your current values with original estimates.  A baseline captures all task values, including ‘Work.’  Weeks or months after capturing a baseline, you can compare those original estimates with current numbers.

To save a baseline in Microsoft Project, choose Tools, Tracking, Save Baseline.  To view all the baseline values, choose View, Table, Variance.  This changes the columns in the current view to show variances to the baseline.

 

–ray

Posted on

How To: Show Critical Path Tasks

Here, we’ll be showing how to display critical path tasks in Microsoft Project.  The critical path is the sequence of tasks that take the longest to reach the project goal.  The steps below can be used to display your project’s critical path.  Follow these, and you’ll know which tasks threaten the final completion date of the project.   Create tasks to display the critical path: Enter three tasks Make the second task twice as long (in duration) as the first task Link the first task to the last task Link the second task to the last task At this point, the tasks should look like this.  Both the first and second tasks link to the last one. Two tasks, links to final task   Group the tasks by critical path: Choose Project, Group By, Critical Or, choose ‘Critical’ from the ‘Group By’ dropdown in the toobar After choosing this menu item the tasks will be grouped differently.  All the tasks that are not in the critical path will be displayed first (in the in ‘Critical: No’ group).  All the tasks in the critical path will be in the second group (‘Critical: Yes’). Tasks grouped by ‘Critical’   Format the Gantt column: Right-click in the Gantt column Choose Gantt Chart Wizard Click Next Click the ‘Critical path’ option Click Finish Click Format It Click Edit Wizard After formatting the Gantt column, the task bars in the critical path will turn red. Critical path task bars are red   –ray

Posted on

When Projects Get Killed

This is a follow-up to the post named “Why IT Projects Get Killed.”  I began to wonder at what stage IT projects get killed.  In other words, when they are canceled.  Most of the projects I’ve worked on have been successful, but I’ve seen my fair share of canceled projects.

For this post, I decided to take a guess at when I felt IT projects are canned.  Of all the canceled projects, these are my guesses at when they occur.  I have no detailed surveys to back up my assertions, just a little experience.  So, here goes…  Post a comment and let me know what you think.

    25% In the investigative stages
    50% In the requirements gathering stage
    10% In the development stage
    10% In the final QA stage
    5% In the pre-sales marketing stage

25% In the investigative stages
This one’s fairly obvious.  A project passes the “good idea” stage and passes into the “due diligence” stage to learn its true value.  That’s when it dies.  Not all good ideas have true merit, or can be marketed effectively with the given resources.  It’s common for projects to die here.

50% In the requirements gathering stage
Here, the project members are interviewing customers and collecting information.  They may even be building prototypes to prove the concept.  But just as in the investigative stages, the idea may die because it cannot meet requirements or marketing expectations.  Again, lots of possible reasons for cancelation, but most of these are because the idea wasn’t feasible.

10% In the development stage
By the time it’s gotten to the stage where development resources are committed, it’s probably proven to be viable or too highly visibility to cancel.  By this stage, the project stakeholders may never cancel it, even if it isn’t viable.  Egos and persistence are at play here.

10% In the final QA stage
Sometimes products never meet customer expectations, or will cost too much to do so.  The project may have gone terribly over budget, and customers hate it.

5% In the pre-sales marketing stage
Surprisingly, some get to this last stage, and still die.  I was once involved in such a project in 1995.  It was killed after two years of intense development, before a single sale was made.  That’s right!  We finished a two-year death march, only to find the product pulled from marketing.  There were too many competitors and not enough customer value.  That fiasco, and a few others like it, eventually killed the entire company.

 

–ray