Project Team Blog

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

We’ve all heard the adage, “Afraid of change”.  It’s preached throughought the business world and even in our personal lives.  We are constantly told to step outside of our comfort zones, embrace change…don’t be afraid!  It is great advice that everyone has faced at some point. 

So why is it that as soon as the media starts telling us how terrible the economy is, we freeze up with fear?  Even in uncertain times we must press forward and get past our fear.  Yet it seems totally acceptable to use the economy as a reason to remain static.  This is bogus.  I agree that we must scrutinize our expenditures and evaluate new ideas, but we should do that in good and bad times.  What frustrates and kills businesses is doing nothing!

If you have an idea to save your company money and improve revenue, why let fear stand in the way?  During good and bad times we must always be prepared to step out and embrace change.  I can honestly say that I’ve had my wins and losses with fear.  However, it always comes down to a simple choice that we make…be controlled by fear or choose to be fearless.  I’d like to hear what you think? Are you driven by fear, or are you fearless?

–Warren

This is not as bad as it sounds.  A lot of companies are in this boat.  They don’t have the revenue to hire full time QA engineers and testers.  So, they do what they can and rely on customers to report bugs, oversights, and possible enhancements.

Let’s briefly discuss how a ‘real’ QA department operates, and then contrast that to the poor-man’s solution.  Normally, a QA manager and team of testers ensure that products delivered straight from the engineer’s drawing boards ship with minimal bugs.  Each tester is assigned one or more areas of the product.  They follow a QA plan and checklist.  Every feature is scrutinized, often put through the paces as real customers would use it.  Bugs are sent up the chain, through the QA manager, and back to the original engineers for fixing.  Once resolved, QA engineers verify the fixes.

A QA department is nice to have.  They find hundreds of issues, and save the company a lot of money and embarrassment.  Product defects are resolved before they hit the shelves.  In the end, the QA department is usually worth their pay.  After all, that’s why the department exists in the first place - to save the company money.

But if you can’t afford the salaries, and you have a small number of customers, the development and manufacturing engineers will need to perform the dreaded duty.  (It is monotonous work.)  Problem is, engineers bristle at repetitive tasks like product testing.  They won’t do a thorough job, and you still end up getting bug reports from customers.  Plus, you’ll have to pay the engineers for their extra testing work - and they aren’t cheap.  Bugs that reach the outside still cost you money in customer dissatisfaction and lost sales, but perhaps not as much as the salaries for a full testing crew.  That’s the real gamble.  And, there are so many intangibles that a true cost analysis of each method is difficult.  But, you’ll know when you need a QA team - when customer complaints begin to kill your product momentum.  When that happens, put together a team quick!

–newshirt

Have you seen the Channel 9 interview with Bill Gates?  The link is below.  The interview is about a half-hour long, and focuses on Gate’s plans for the future as he transitions out of Microsoft and into his philanthropist foundation to help the poor.

http://www.microsoft-watch.com/content/corporate/a_month_of_gates_7.html

Here are some quotes I found interesting.  These are the kinds of lines that drive my own thinking.  They drive me to fight for our brand position in the marketplace.

You’ve got to have product plans for every product you expect to release in the next few years.  And those plans have to be very realistic.

 Making sure we take some risky bets.

We are a very self-critical culture.

Software seems to be so complicated…  Software has some composability today…  But we have to make it easier to write big software.  We’ll have a lot more progress in the next decade.

 It’s always surpring to me there’s little attention paid to what we are doing for business users.

We care about the information worker.

We’re always sharing about where were going so people can make plans.

Best of luck, Bill.  Care to comment on the Channel 9 interview or this humble post? 

–newshirt

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

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

Having varying points of view is healthy for company growth.  However, sometimes the varying opinions have underlying meanings that aren’t always what they seem.

For instance, how often do IT teams resist implementing new programs out of fear, laziness or just the extra work it creates?  I mean they are tasked with everything from support desk tickets, computer set-ups for new employees and even firewall security.  So it’s easy to get bogged down with the extra work a new program rollout will cost instead of focusing on the big picture and long term benefits.  Other times people resist out of simple personality conflicts.

When this happens you will hear legitimate-sounding excuses of how the installation may conflict with another program or of how it may take up too many resources.  This happens because one manager doesn’t want to help another manager or due to many other normal and very human reasons.

So the next time you have someone objecting to what most everyone else is pushing for, ask yourself, “Why?” It could be a very real objection worthy of consideration.  Or, as I found out last week, it could be a person impeding progress because they simply do not want to put more work on their plate.  The tough part is determining which is true. After all, we are all human!

–Warren

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

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

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

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

I thought I was done with this subject last week.  But then it struck again, Analysis Paralysis!  I am near completion of a deal that is over 4 years in the making, not for me, but for a fortune 100 company.  In other words, they’ve been work it this long.

This company has been looking for a solution and had contacted one of our reps back in 2003.  They were about to move forward with the implementation but someone convinced them to wait, and ultimately pushed to build the program in-house.  It’s the same story I hear time and again, “we can build it in-house for half the cost”.

Yeah, right.

So here I am in a conference call with a handful of representatives from this large company and they are sharing with me how after 4+ years they couldn’t build a good tool and wanted to use ours.  This happened for a number of reasons.  Reason #1…It’s not what they do!  Sure it looks easy, but when you actually set out to do it, reality hits.  Reason #2…not enough time.  Building a tool takes away from their core business, and that always takes a back seat.

Suppose I wanted a nice wooden baseball bat and I see that Louisville Sluggers cost $29.  If I’m not careful I could be talked into buying a piece of lumber, sticking it on a wooden lathe and saving myself ten bucks to make my own.  We all know that would be a disaster. Yet somehow in business we don’t always take that same common-sense approach.  Instead we waste too much time arguing, waiting and losing money.  Isn’t it better to pay a small premium for another’s well invested expertise?

Waiting usually costs more than doing nothing or delay.  As one CEO recently said, “After hearing all the facts, make a confident decision, even if you aren’t certain.  It’s indecision that is costly”. 

–Warren

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

Biblically, 7 is the number of perfection, and 6 is the number of “man.”  Remember 666, the “number” of the Antichrist?  In light of that, I’m going to enumerate the worst sins consulting companies can make.  These are the ones that doom them to hell on earth.  If you’ve been in business for any length of time, you have probably already nailed these and gotten past them.  But they may be worth reviewing.

#1: Ignoring your customer’s complaints
The customer is always right, right?  No, not true.  But, when they believe they are right, you had better be there to work things out.  Sometimes you can make them see your position in a disagreement, but more times than not, you’ll need to suck carpet and make things right.  That’s part of what they expect of the relationship.  The mere fact that you take money from them puts you in that position.  Cruel fact of life - get used to it.

#2: Failure to smooze
This one is akin to the first, but slightly more on the positive side.  Remember the old adage “out of sight, out of mind?”  That’s what happens when you haven’t had face-time with your customer in a while.  They literally think less of you.  The relationship grows cold and they are less likely to call on you when a need arises.

#3: Letting sales slip
Consultants and consultancies have two big jobs: consult and sell consulting services.  Both are equally important.  Once a gig has been landed, the tendency is to settle in and forget about what comes next.  Looking for the next gig is hard.  It’s much easier to do what you’re competent at, and let the sales work take care of itself.  Problem is…  it often doesn’t.  When the gig ends, you’re on the street again without work.

#4: Shoddy work
This one’s so obvious, it’s hardly worth mentioning.  But it really goes deep down to the type of person you are.  Keep your standards high.  Remember that you are competing with other consultants, and for future work.

#5: Low utilization
Got a nice high billing rate?  Higher than working at Wal-mart?  Consider this: your “effective” billing rate (or utilization rate) is your revenue divided by the total calendar hours.  For example, $50,000 divided by 2,000 possible billable hours in a year is an “effective” rate of only $25 per hour.  You may charge $100 and hour for your time, but only book 25% of the total possible hours.

#6: Not picking up the scraps
Nobody likes to think of themselves as a handyman who takes odd jobs.  We’re skilled professionals with higher education.  But there’s no shame in stooping down to pick up small jobs.  Sometimes you can even charge more for them.  They can fill gaps between the big gigs and give you interesting new experiences.

–ray

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:

1. Enter three tasks
2. Make the second task twice as long (in duration) as the first task
3. Link the first task to the last task
4. 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:

1. Choose Project, Group By, Critical
2. 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:

1. Right-click in the Gantt column
2. Choose Gantt Chart Wizard
3. Click Next
4. Click the ‘Critical path’ option
5. Click Finish
6. Click Format It
7. 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

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

We’ve all heard the term analysis paralysis, and frankly it is a millstone around the necks of many corporations, especially ones that are heavily layered in management.  In today’s world economy only the quick and flexible survive. 

Imagine you have a great idea you spend days, if not weeks, researching.  You run the initial numbers and cost analysis that shows a marked improvement with a bottom line benefit.  You can hardly contain your excitement!!  So, let’s get started, right? Wrong!

Bob, over in development, isn’t sure this will actually save the company money and he thinks they “might” be able to build their own tool.  So he talks to Chris in accounting and before you know it there are too many cooks in the kitchen and everything is on hold!

It took 6 months before a decision was made to build this tool in-house.  It took Bob’s team over a year to figure out they couldn’t build the tool properly, and they spent 12 times the amount the original “off the shelf” implementation would have cost!  And the final result?  Still waiting…

If they had simply gone with the original idea of an off the shelf tool they would have saved the company enough money to buy the thing 20 times over!  Instead they’re back at square one.

I am all about due process and thinking things through.  However, at some point a decision must be made and all too often one isn’t made out of fear, job security, or simply because someone is being territorial.

This is a common story and that’s why strong leadership is important.  If you’ve done the homework and you know it’s a worthy endeavor… push, push and push some more.  In the end you will be rewarded for a job well done or sleep well knowing you gave everything you had.  To use a sports term, “Leave it all out on the field.”

–warren

Don’t get discouraged; losing your best people is not as hard as it sounds.  And we’re here to help!  We’ve offered a few good ideas below.  If you have others, please post a comment, and they’ll be added to the list.  Why remain in agony, when the answers are so simple.

#1: Make life easy
That’s right; lavish money, benefits, and perks on your best people.  Foosball, anyone?  They’ll relax from the high-tension goals you’ve set, and things will slowly go undone.  Small things.  Your competitors will make life hard for you, and remove your ability to compensate so graciously.  Your best people will leave as a result.  Harsh realities, but you can pull it off!

#2: Lower your expectations
Why treat your best people like slaves?  They’ve worked hard to get where they are today, and they deserve a rest.  After all, you don’t want to be known as the Pharoah’s taskmaster.  Trust me… this works.  The results will be similar to point #1.  As soon as they realize the company and project goals are negotiable, you won’t have far to go.

#3: Create a Dilbert environment
Don’t know Dilbert?  See the comic to the left, or click here to see the cartoon.  Poor Dilbert is an IT professional who faces more daily incompetence than an Oklahoma Street-sweeper.  (Get it?  Armadillos?  That was my own pitiful attempt at humor.)  :)  Foster a certain degree of incompetence in the office, and your Dilbert will flee.

#4: Let your projects take care of themselves
They will, you know?  Project management is not a discipline, its a recreation.  Don’t track your project time.  Don’t bother with post-mortem analysis and percent complete.  If you must, use a little spreadsheet with some cool fonts and colors.  Your best people will drift along with you - until their job search pays off.

All kidding aside, people leave for a lot of reasons, and it’s not always the company’s fault.  Don’t beat yourself up too badly.  If you’re trying hard to keep good people, you’re probably doing okay.  It takes a pretty messed up organization to drive good people away.  And sometimes, even the best companies cannot keep them.  Keep up the good work, and don’t let these things happen to you. 

–ray

Deadline: A date associated with a task’s finish date, after which an indicator appears in the ‘Information’ column of Microsoft Project.

Microsoft Project allows you to set a deadline date for each task in an MPP project file.  This date is closely linked to the task’s finish date.  See the link below to set a deadline for a task.

http://www.projectteamblog.com/?p=43

I prefer deadline dates to task constraints.  They are simple and informal, and do not affect downline task dependancies.  In other words, they simply show a red symbol next to the task rather than affecting the starting dates of other tasks.

But honestly, Microsoft Project® is not as elegant as Standard Time® when it comes to time-related things.  It has no timesheet, and cannot accurately track employee hours for tasks.  Obviously, there is an ‘Actual Work’ column, but has no effective way to fill it. Standard Time® is much better suited for that purpose, and it has a task deadline feature as well.

–ray

I like CIO Insight.  They seem to hit a lot of relevant issues.  Their “Why IT Projects Get Killed” is a short slide-show with a simple breakdown of the top five reasons IT projects get killed.  A link to the article is below, and I’ll comment on the top reasons.

http://www.cioinsight.com/c/a/Management/Why-IT-Projects-Get-Killed/

Reasons:

1. 30% Business Needs Changed
2. 23% Does Not Deliver As Promised
3. 14% No Longer a Priority
4. 13% Exceeds Budget
5. 7% Does not Support Business Strategy

Well, that’s only 87%.  I suppose the other 13% fall into the “Other” category.  I’d like to take a crack at interpreting the numbers.  Here are my thoughts on why IT projects are killed.

30% Business Needs Changed
From the time a project is first proposed until it is started, things have changed.  These are often projects tightly connected to cultural events.  For instance, your proposal for a new drive-through pharmacy may lose 7% of its expected revenue if the price of gas goes to $5.  Anything that tightly connected to consumer behavior must be watched closely.

23% Does Not Deliver As Promised
Oversell and hype.  Lots of people do it, and lots fall for it.  It always surprises me how pessimistic people are when investing money, but how easily they fall for a good story.  Almost a quart of the projects don’t live up to the promise.  But it’s not jsut hype that contributes to this number.  Sometimes people simply don’t realize how big a project is when they start it.  That’s understandable.

14% No Longer a Priority
This feels like reason #1.  Business needs change, and the project is no longer a priority.  But I suppose there other reasons a project may no longer be a priority: Can’t make money at it, Other solutions have arisen to replace it, Employees or customer have changed.  But still…  aren’t these all “business needs.”  If so, a full 44% are canceled just because “things change!”  Yikes!

13% Exceeds Budget
I expected this to be higher.  Most people I talk to go over budget on their projects.  That’s why they use products like Standard Time®.  They know they’ll be cancelled if they go over .  Well, maybe it’s doing its job!

7% Does not Support Business Strategy
This happens when unlearned individuals go off on exciting missions that the executives don’t support.  A project gets started, but killed soon after - once it’s discovered to be nonsense.  I’ve run into quite a few of these individuals.  But I don’t fault them; they try.  And that’s all the CEO really expects of them.

–newshirt

Ever wonder how to reduce your Microsoft Project file from thousands of tasks down to a manageable few hundred, without deleting any?  Have you tried filtering?  This post discusses the steps to filter tasks in Microsoft Project.

Filtering is the act of reducing the number of visible tasks so that you only see what you are interested in.  All the tasks will still exist in the MPP file, but you will only see tasks that correspond to your filter criteria.  Follow these steps to filter tasks in Microsoft Project.

Create some tasks to filter by:

1. Enter three tasks
2. Set the durations to 10 hours, 20 hours, and 0 hours
3. The results should look like the image below

Set up a new filter to show long tasks only:

1. Choose Project, Filtered, More Filters…
2. Click New
3. Enter the name “Long tasks” (without the quotes)
4. Click ‘Show in menu’
5. Click in the ‘Field Name’ column, and choose ‘Duration
6. Click in the ‘Test’ column and choose ‘is greater than’
7. Click in the ‘Values(s)’ column and enter 10
8. Click OK to save the new filter
9. Nothing should change in your view

Activate your task filter:

1. Choose Project, Filtered, Long Tasks (the new filter you created)
2. Your view should now look like this image (hiding all the short tasks)
3. Choose Project, Filtered, All Tasks to remove the filtering and show all tasks

–ray