Project Team Blog

My definition of “default behavior” is: doing what 90% of the world’s population does, when faced with a new or unfamiliar situation.  Panic and give up.  Let me explain.

The “average guy on the street” almost always acts the same way when faced with something new or unfamiliar.  He throws up his hands and asks for help.  No thought.  No research.  Just give up and ask for someone else to do it for him.  “Tell me how to do it.”

If you expect to manage projects or people, you must learn how to think independently.  And learn how to handle unfamiliar situations without exhibiting “default behavior.”  Here are some examples:

You are asked to download a program:

Default behavior: “What’s the URL again?”

Better: Google the name or look it up in your list of products.

You are asked to reconfigure all the users in a certain program:

Default behavior: Call tech support and ask how

Better: Explore the program and learn it

Your project is over-budget and stalled:

Default behavior: Ask for more money, time, and resources

Better: Huddle up and cut secondary priorities

You may not suffer from these exact scenarios, but the general advice is sound.  Learn to recognize your responses to unfamiliar and stressful situations, and improve them beyond the default behavior.  Career advancement depends upon it!

–ray

Here’s a small piece of advice registering as a user on this (or any other blog).  Don’t look like a spammer.  Because your account will get deleted for sure.  We won’t even ask first.

What do I mean by that?  Make sure you provide a little personal information about yourself.  Nothing that will get you into trouble, but enough to let us know you’re a human being instead of a spambot.  Spammers attack the blogs regularly, trying to register with fake names so they can post “comments,” which are really just ads for crap.  Its a despicable practice, one that requires a complete lack of integrity and moral backbone.  But hey, if your in the spam biz, you don’t have those luxuries.

–admin

I have written in past blogs about Project Management being a lot like coaching. One part of this I want to elaborate on is our words. I can imagine, in the heat of battle, coach Paul “Bear” Bryant would drop a few “f” bombs on a player, get in his face, and challenge him to do more–and to do it better.  That does not fly as well in the corporate world. A football player can rush on the field and translate that aggression into physical action. It works on the field but not so much in a cubicle.

However, in the office, a manager must still learn to pull the right strings and push the right buttons. The best way to do this is by getting to know your team. Use personality profiles, spend time with your employees sharing their interests, and things outside of work. Then, you will have a better feel for who needs a kick in the pants and who needs a pat on the back. NOW GET YOUR TAIL OUT THERE AND MAKE SOMETHING HAPPEN…and do not drop the ball. 

–Warren

CIO Insight had a short article that got my attention.  See the link below.  It caught my attention because it lists the business areas where CIO’s are not typically involved.

http://www.cioinsight.com/c/a/Foreward/What-IT-Leaders-Dont-Do/

Areas CIO’s are not involved: 

1. Choose geographical markets to enter
2. Choose product markets to enter
3. Choose product lines to enter
4. Hiring non-IT employees
5. Acquiring other companies
6. Merging with other companies

I’d like to hear your opinion!  Should CIO’s be involved in these areas?  The first three are the domain of sales and marketing executives, and the last three belong to the CEO (who the CIO normally reports to).  So what involvement should the CIO have in these areas?  I would think little, if any.

CIO’s typically care about the information infrastructure of their organizations.  So how do these things apply to that.  Well, there’s web sites, databases, web services, network traffic, logins, etc, etc, etc.  I suppose that’s a fair degree of overlap.  But does it warrant anything more than a token seat at the conference table (when discussing the issues)?

Your thoughts?

–ray

I have been in sales and marketing for some time now and I work with Project Managers (PM’s) nearly everyday. It struck me the other day how similar PM’s and sales forces really are. Project Managers are sales people on many levels. Project Managers often have to sell the benefit of an idea to get their teams motivated. Project Managers identify problem areas to avoid, as do sales professionals.

An interesting twist on this is taking the problem a step further and identifying the problems’ implications and consequenses in any given project.  It is one thing to note a specific problem, but if you really want to wake the team up, talk about the implications of that problem in greater detail. Bring up examples of likely scenarios and issues that could arise. By stressing the implications, you will put a magnifying glass on the issue and focus on the ways to avoid that pothole! After all, problems come and go, but the consequences may not.

–Warren

Being consistent in your management style and personality is important for success. One of the first lessons in parenting is being consistent.  If you discipline your child one time for something, but then ignore that same thing a different time, you are sending a confusing mixed message.  Obviously, your project team members are not children, but the principle still applies.

Our teams depend on us for leadership and direction. As managers, if we are on a roller-coaster of emotion, our project teams will be all mixed up.

My manager when projects are late

Inconsistent behavior stifles creativity and does not allow a tolerable environment for ideas to be exchanged.  If a team member is not sure how you will react from one day to the next, they are less likely to be forthcoming with ideas and suggestions.

No matter how crazy a project becomes or how much stress leaders are under, we must be the model of consistency.  Like the commercial says, “never let them see you sweat.”

–Warren

Our company develops a line of products.  We sell the same off-the-shelf design to many customers.  They all essentially get the same thing: a downloadable product with a certain set of features.  But there is always somebody that needs something a little different.  That’s when they become “special.”

Developing special features for a single customer can pose special challenges to an off-the-shelf product.  This post discusses three of those challenges.

My biggest concern is punishing 99% of the customers with a feature that only 1% will use.  Suppose you add a new feature to the product that 1% of your “special” customers will use.  The other 99% may not understand it.  That’s a bad thing.  They’ll think they need to understand it, and will spend time studying it, only to learn that it does not apply.  My advice: make sure that doesn’t happen.  Bury it where only the most adventurous will find it.

The next concern is maintenance.  If you create a new feature for one customer, guess what…  You’ll have to make sure it stays working forever.  It will cost you money as long as you maintain it.  Make sure you get that money up-front, or in maintenance payments along the way.

Have you given any thought to the effect your “special” features have on the rest of the product?  In other words, will these one-off features break something else.  The more complex a product is, the more likely collateral damage will occur.

The upshot is that special features cost more money than you might think.  But you have to do them to gain new customers and satify existing ones.  It’s all part of the game.  Just make sure you are profitable doing it.

–newshirt

We’ve all heard the saying, “the customer is always right.”  So when a customer and vendor disagree, it implies the vendor is always wrong.  I realize this is a customer service driven idea meant to teach us to take care of our customers.

However, I have seen companies blame vendors all too often, without examining their own shortcomings.  This is an epidemic in our culture, it’s always someone else’s fault and no one wants to be accountable!

Just this week I had an opportunity to do business with a major U.S. company.  A company most everyone has heard of but will remain nameless.  To my surprise I lost their business at the last moment.  In fact, one of the VP’s had stated just days before, “I am ready to cut you a check tomorrow.”  The deal was done, right?  Well, not exactly…after a lot of meetings and numerous discussions met with many delays.  I was told that we (the vendor) were missing a key component.  What’s ironic is that I did countless demo’s and was assured that the deal was done.  The missing feature was never mentioned.  Then bam, it’s over!

We may have been able to accommodate this last minute need, but we’ll never know! We will continue to do business and press forward and I will examine what I could have done differently. 

How can a major company have a year and a half of meetings, discussions, and reach the end of a path only to find out that they didn’t really know what they wanted and then simply brush it off as a vendor problem?  It always hurts to lose business, but the vendor isn’t always be wrong.

–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

How do you know when your product is ready for release to waiting fans?  Does it have what they want?  Is it high enough quality?  Will it crash and burn, costing you thousands of dollars?  Tough questions.  Unfortunately, there are no great answers, but consider the following factors.  They may help.

Keep it foundational
There’s always a temptation to boil the ocean with your grand scheme.  To have the best product in your class.  After all, you’ll never make money without it.  But this is a trap.  Great products take years to develop, and if you wait that long, you’ll never get a foothold in the marketplace.  It’s far better to get started early with a foundational product, and constantly improve it.

Listen to customers
Every feature in your product should come from customers.  Don’t invent stuff yourself unless you are certain it’s the next great thing, and then still don’t.  Chances are, you’ll have a tough time selling pipe-dream features that customers don’t ask for.

Always ready for release
This only applies after you have already released the product at least once, and applies best to iterative products like software.  Never dive so deeply into new features that you can’t release the product at least once a month - even when doing major upgrades.  Release the product frequently to beta testers and trusted customers, but don’t let it stay “down under” too long.  This keeps the bug count lower, and keeps you closer to customer input.

Test twice, and twice again
If you’re like most engineers, you’ll spend half your time polishing and fixing bugs.  But many don’t realize that.  They want to blaze new trails and invent new things - all the time.  But you can’t make a living like that.  Be patient with your product, allowing it to mature into a robust system.  Don’t walk off until you are sure it is.

Good luck with your release, and let me know how you made out. 

–ray

On the surface, resource leveling looks appealing.  It offers the ability to spread work out so that an employee never has too little and never has too much.  Sounds good, right?  Maybe not…  Read on and let me know what you think.

The problem I have stems from the term resource itself.  Some of my customers won’t even use the word because it turns employees into machines.  Are “resources” human beings?  No, they are just “things” to be used.

I don’t go that far with my interpretation.  I’m okay with the word “resource.”  I know what it means, and what it doesn’t mean.  But still, when software attempts to tell the employee when to work, something is wrong.  Shouldn’t it be the other way around?

Spreading work around (as is in resource leveling) removes the human element from the project.  It turns employees into machines who crank out project hours, task after task after task with no regard to content.  One task is the same as another, right?

I’m sorry; people don’t work that way.  Machines do.  They love steady work.  Give them something to do, and they will churn it out day after day.  People work differently; they are diven by passions and love for the job.  They get excited about one task, and then another.  They schedule them in order of passion for the task at hand.  No passion - no work.

As soon as you allow software to tell your people when to come and go, the passion is gone.  Make sense?

–ray

I had the misfortune of incorrectly accusing a vendor, one of my company’s main suppliers, of neglect. It turns out…they weren’t neglectful at all!  I was wrong and had received bad information!!

I worked in the new product engineering group with a company that sold a lot of knick-knacks, similar to what you find in card shops like Hallmark.  We did catalog sales without a storefront.  My company had tens of millions in annual sales.  Part of my job was creating a new quality control program to improve the products we purchased from our manufactures.

One bright day I sat across from our main supplier and delicately challenged them on a few quality issues we had found in one of our recent audits.  You can only imagine my embarrassment to find that the product I trashed, was not theirs!  An auditor on the QA Team had incorrectly identified this problem product with the wrong vendor!  I had discussed three products in total, two of which belonged to them, the third did not.  Rather than making progress and improving the two products correctly identified as theirs, I spent the better part of two hours mending fences and eating crow.

Needless to say I had a long discussion with the auditor that filed the flawed report.  We put in place procedures to double check and verify products and correctly assign them to the right vendor.  I learned a valuable lesson that day.  Accuracy is important and usually doesn’t take much effort.  This was a lazy mistake that nearly brought down a 10 year relationship and wreaked havoc for thousands of other people.

Whether it is simple or complicated…having solid accurate information is a must.

–Warren

I’m going to put in my two cents regarding the sexification of enterprise software.  The argument of whether enterprise software needs to be sexy (to keep up with consumer products) is still on the table.  See the CIO article below.  I vote “Yes” and here’s why…

CIO article by Brian Watson: Newer innovations like software as a service, Web 2.0 and mobile applications are broadly available to those outside the IT department. For those consumers of business software, freshness and flash are key selling points.
http://www.cioinsight.com/c/a/Foreward/Why-Enterprise-Software-Must-Be-Sexy/

Enterprise apps are made to serve a specific purpose.  They track project time (like Standard Time®) or access human resource records (like SAP®), or any number of specific jobs.  People use them every day, and their value lies in the depth of service they provide.  Apps that do a lot, command the big bucks.  Try to replace them, and you’ll have a huge battle.

But still, people have to use them every day.  And if they don’t like them, they gripe.  That huge battle to replace them suddenly looks pretty small compared to dealing with unhappy employees.   No big app can last forever in the face of employee dissatisfaction, regardless of its value in the enterprise.

And guess what?

All those employees have consumer items they compare the enterprise apps to.  Cell phones, big screen TV’s, PDA’s, cordless phones, etc.  They begin to expect the big enterprise apps to employ some of the sexy usability enhancements they find in their personal consumer items.

Think about it…  Would you rather use an enterprise app with 80’s-style “VCR” controls or those of your cool new MP3 player?  That’s why enterprise apps need to be sexy.

–ray

For product development teams, outsourcing almost always means “buying time.”  Every project has three aspects in contant tension: Time, Cost, Quality.

1. If you want to save time and get your product to market faster, you can pay more (cost) or make a smaller product (quality).

2. If you want to spend less money, you can delay the delivery date (time) or cut features (quality).

3. If you want a high quality product, you can spend more money (cost) or wait for it to mature (time).

Outsourcing clearly cost’s money.  So why do it?  To get your product to market faster, that’s why.  You are spending the money now, so that you can recouperate it earlier.  Beat the competition to market.

No?  You’re not doing it for that reason?  You’re using India as a cut-rate development shop?  Oops, that may be a mistake.  Remember the other aspects in constant tension?  Quality is one of them…

–ray

I once worked for a large company as a QA manager.  One day word got out that our VP of Customer Service was on the war path because damage complaints were up over 33% year to date!  It was costing us a lot of money to resend orders that were damaged upon arrival at our customer’s locations.

 I was a mid-level manager at the time and only heard rumblings from my superiors from high level meetings they attended.  I was instructed to change product packaging to hundreds of items, perform drop testing and all sorts of comparisons to reduce damage complaints.  Nothing worked.  After about six weeks of panic and fact finding no one had arrived at a reason for the problem .

Then one day I sat in on a high-level meeting.  I recalled a friend of mine that worked in our  call center telling me how we started resending new items, instead of coupons for damaged products.  It just so happened that our system calculated damage complaints based on resent items, not coupons.  I mentioned this during our meeting; we crunched the numbers and determined that damage complaints were NORMAL!  No increase had ever occurred, only the way we calculated them!!

I would have given anything to avoid those six weeks.  We invented new procedures, hired consultants and changed all of our packaging!  If only we would have talked about this before we initiated the changes!  Communication, although not always easy, is always essential.

–Warren

The four C’s of diamond cutting are Color, Clarity, Caret, and Cut.  Every stone is judged on these characteristics, and the price set accordingly.  My assertion is that these qualities also apply to the art of product development.  Engineers and Product Managers, listen up!  The value of products for your customers follows the same principles as cutting and polishing a beautiful stone.  Indulge me, and I’ll explain.

1. Color.  People expect beauty in the products they use, and will always choose a pleasing product to an ugly one.  This aspect of project development refers to the almost imperceptable touches of style you add to your work.  As left-brain engineers, we often overlook this.

2. Clarity.  Have you applied a ‘usability test’ to your product?  How clear is it?  How easy is it to navigate and complete the basic tasks?  Consider using a digital camera to study people using your product.  You’ll learn a lot about clarity and usability.

Polish: Refers to any blemishes on the surface of the diamond which are not significant enough to affect the clarity grade of the diamond. Examples of blemishes that might be considered as ‘polish’ characteristics are faint polishing lines and small surface nicks or scratches. Polish is regarded as an indicator of the quality of as diamond’s cut; it is graded as either Ideal, Excellent, Very Good, Good, Fair or Poor.

3. Caret.  Is your product full-featured?  Is there a lot of value?  Consider building it out to offer more for the money.  But listen closely to customers before launching into your build-out program.  Find out what they want, and add only those features.

4. Cut.  There a dozens of ways to present a product (i.e. cut the product features for use).  Choose an ugly one, and customers will look elsewhere.  They want new ways to approach their problems.  After all, they have exhausted all the conventional wisdom, and are looking to you to solve the real jawbreakers.  Do it, and they will reward you.

–ray

Blogs, wikis, and social networks top the list for collaboration tools among project team professionals, right?  After all, they bring the entire team together in ways nobody ever thought possible.  But that’s not what the latest Ziff Davis study found.  In fact, “shared project management tools” was in the top ten, up there with simple old email.  Didn’t know that?  Check out this article by Allan Alder at CIO Insite.

http://www.cioinsight.com/c/a/Research/Collaboration-Unlocking-the-Power-of-Teams/

It’s buried on page five, but the zinger quote below tells it all.  Check out the chart on page 5 too.  It tells us that products like Standard Time® really are important!  They are the ones bringing project teams together.  “Shared project management systems” ranked at #8, while “MySpace” was at #27, just above “None of the above.”

Shared project management systems, workflow systems, real-time document collaboration tools and knowledge management systems are considered more important than any Web 2.0 technology: They are widely used by project teams and, to a slightly lesser extent, by co-workers engaged in business processes.

I’d like to see the list of collaboration tools you find useful for your project team.  If you are not using Standard Time, what are you using?  I’d like to hear!

–ray

A huge number of projects, usually small ones, die ugly drawn-out deaths simply from distraction - and nobody knows.  Yeah, people get distracted and forget them!  It’s true, I’ve seen it happen dozens of times.  Here’s how it happens.

First, the big boss decides he wants something.  A new product or policy.  A new way of doing things.  An improvement in procedure.  He’s sure it will save the company money, so he launches a new initiative (a project) to get it.  He assigns it to one of his people, and expects to hear some status in a while.  FIRST MISTAKE!

The employeee may have no strong allegence to the new initiative, and gets distracted and never completes it.  He’s bored, and doesn’t want to mess with it.  The boss forgets he asked, and the project is effectively dead.  Every seen that happen?  That what I thought…  So, how do you fix it?

Tip #1: Document it.
If you don’t write down your project initiatives, they can easily be sabotaged by bored employees.  If there is no record of them, employees can safely ignore them without any consequences.  And they will.

Tip #2: Don’t pile on.
Giving your employees too many projects means they won’t do them when asked.  I’ve seen managers throw so many projects at employees that they simply ignore them until asked later.  If the big boss never asks, he must not want it badly enough.  They simply wait him out and deal with only the important ones when he asks.  Yikes!

Tip #3: Reduce the chain links
If Joe is to do the job, but needs input from Britnney and Travis, and they can’t get to it until Keyshawn obtains his status from Lisa who gets her materials from Joe, you may never get anything.  Don’t believe it happens?  It does.  There are sometimes so many links in the project chain that the effort fizzles out, simply because one person can’t get what they need.  Of course, they never bother to find out why, but you need to realize this can happen.

Bottom line: you need a project champion who walks everything through its paces.  If you’re the big boss, that may be you.  No champion?  Well… chances are the project will die of distraction.

–newshirt

Are you the leader of a project team?  Or do you hope to be someday?  Here’s a tip for managing people.  Love what you do.  And show it.

If you are in leadership, you will not have success until you love your work so much it’s contagious.  People need to see you digging into every aspect of it.  And digging hard.  They simply will not follow until they see the passion.  Are you uncovering new ideas and methods?  Finding improvements in managing projects?  Making it look fun?

Think of things through your team member’s eyes.  Do they see someone who can take their careers to the next level?  Sure, you may be a good ol’ boy, but do they feel compelled to follow you?  Fight for new business?  Endure the pain for the pleasure of success?  Not if they don’t see you doing those things.

The point I’m making is that managing teams, projects, and products is more about leading by example than begin one of the gang.  Be a person they want to emulate.

–ray

I suppose it’s no surprise, but I for one, perform better when under the influence of inspiration.  My projects just flow when I am driven with excitement to complete them.  I don’t even have to ignore the boring aspects of the project; I just fly right over them as if they didn’t exist.  But without that inspiration, it’s sometimes a drag.

Okay, that’s me.  Now, how do you get the entire team motivated like that?  All at once?

Clearly the answer lies in goals that every one shares.  Fame, fortune, accomplishment?  It’s different with every project, and every person.  The key is to find common ground that everyone can get behind.

I remember the old MacPaint program on the early Macintosh’s.  All the author’s names were in the About box.  Those guys met in Andy Herxtfeld’s home, and pounded out the next great thing: Fatbits!  But there’s no simple formula for every project team and every project.  In other words, you cannot simply offer comp time or best-employee certificates for every job.

Years later, names in the About Box isn’t enough.  Been there, done that.

Eventually, people grow weary of simple incentives.  They need big “life incentives” that mean something to their lives.  They need to know their efforts are making a difference in the world.  That people recognize their work.  Yes, it takes that much.  Nobody wants a shallow life.

How do you inspire your team, all at once, to change the world?

–newshirt

In this post we’ll discuss how to split tasks in Microsoft Project.  In other words, how to break tasks into segments representing the exact times work will be performed.

Microsoft Project tasks do not necessarily need to start on one day, and continue until the task is complete.  They can be broken up into segments.  In other words, work can be performed in a discontinguous fashion.  For instance, 16 hours in one week, 16 hours in the next week, and a final 4 hours the following week.  This technique is illustrated below.  Steps to perform it as also included.

Split bar, showing each segment of work

Split hours, in Task Usage view

I must warn you…  I feel this is a micro-management technique.  It can be good to define exactly when the work will be performed, right down to the hour, but do you really want to spend your time doing that?  That’s better left to the discretion of engineers who will actually be doing the work.

Follow these steps to split Microsoft Project tasks:

1. Create a new task in the Gantt view (See the View menu)
2. Right-click in the header area, and choose Insert Column
3. Insert the Work column (it represents the planned work for a task)
4. Enter 10 hours for the Work
5. Choose View, Task Usage
6. Notice the number of hours for each day (this is the time you will work on the task)
7. Skip a few days, and enter some additional hours into the Task Usage view
8. Choose View, Gantt Chart to return to the preview view
9. Notice that the Gantt bar has been split to show the new hours

–ray

This is a little reminder that we all need from time to time.  I’m not going to get too depressing here, but I attended a close family members funeral last week.  As I talked with family and friends at the service I was reminded of what’s truly important in life.

We all know this, but rarely stop and do anything about it.  We get caught up in the daily grind and focus on the latest hurdle at work.  Well I’m here to say that last year I said forget it, and took my family on a 10 day vacation!  We spent time at the beach and doing a whole lot of nothing.  During this vacation I got to spend time with my aunt whose funeral I attended last week.  I remember chasing and catching fireflies with my children in her backyard, priceless.  Jeez, I’m a city boy raised in So-Cal.  And during that time I got to ride on my grandpa’s tractor around the old family farm.  I am so glad we took that vacation!  These are just a few memories that no one can pull from my mind.  It was relaxing and it was more fun than I ever thought it could be. 

Life will always bring excuses as to why we can’t slow down to enjoy time with family and friends.  We Americans work harder than any people on earth.  Yet we ought to recharge and relax once in a while.  What are one or two weeks out of the year?  For me its a lifetime of memories and more fun than I ever dreamed.

I just got off a conference call where the customer lamented that project tracking (in his organization) is an albatross.  E.g. too much work!

His company had been using an Excel spreadsheet, and wanted to switch to Standard Time® for project tracking.  Their spreadsheets had grown so large that grooming them consumed too much time.  His statements really got me thinking.

Every project has two components: doing the work, and managing the work.  That’s no big secret.  This person was lamenting about the management part, and wanted to know how Standard Time® would improve that.

Unfortunately, the answer is not in the tool, but in his organization.  Questions arose regarding the size of his teams, their self-sufficiency, and how granular his tasks needed to be.  We agreed that his tasks were too granular - too small.  He had been trying to micro-manage everything, and that was driving him crazy.

Let’s face it, project tasks change frequently.  It’s nice to document every task you’ll work on, but in practicallity, some well-defined buckets could catch all the task work.  Each time log could describe the work performed, and you’d still have some basic tasks to report on.  Simplicity is best.

eWeek published a little piece in the Application Development department regarding Web 2.0 collaboration.  (See a link to the article by Darryl H. Taft below.)  The upshot is that developers have been using Web 2.0 collaboration for years.  It’s the rest of the world that’s just catching up.  How about you?  What Web 2.0 technologies do you use?

http://www.eweek.com/c/a/Application-Development/Developer-20-GungHo-or-Ho-Hum/

I use the following resources pretty regularly.

1. codeproject.com
2. codeguru.com
3. msdn.microsoft.com
4. projectteamblog.com
5. projectteamwisdom.com

Honestly, I’m not a big web surfer.  I don’t spend a lot of time subscribing to RRS feeds and plugging into the forums - with the exception of projecteamblog.  I don’t even have special ringtones.  Web 2.0 is not that exciting to me.  I’m not much of a social networker.

Tell me why I’m wrong!  What am I missing that could help in the areas of project management, application development, and team management.  technorati.com says there’s 11 million blogs out there, plus or minus 500 million that come and go every month.  I must be missing something!  I’d like to hear your comments…

–newshirt

What percentage of your organizational time is spent on business-driven projects?  In other words, how much time is spent working for customers?

Even a one-man operation must worry about this number - this percentage of customer-driven time.  Every organization has projects they do for customers, and projects for in-house development.  The balance between them is what I’m talking about.  Do you know your percentage?  Do you track your project time?

I’d like to think that 90-95% should be customer-related.  Any lower, and you’re probably spending too much time fiddling with non-marketable work.

I once worked for a company that wrote all their own software development tools.  At the time, Microsoft was selling full-featured compilers for $300.  Yet this company wrote all their own.  In their case, I would guess their customer-drive project time was less than 80%.  That’s too much time fooling around with internal tools.

A company with that much time on their hands won’t do well.  What say you?

–ray

I know a person (who will remain unnamed) who uses a little trick to work on projects.  When starting a new job, she does just a little bit the day before.  When she comes in the next day to begin the project, she’s happy to see that there’s some done already!  And then, she can continue where she left off.

Nobody likes to start a new project with a blank page.  Yuck, where do I begin?  That small hurdle is sometimes enough to make you procrastinate a whole other day.  Yes, I do it too!  I have hundreds of small projects I’m responsible for, and sometimes I can’t bring myself to start another one.  To avoid a new one, I’ll putter around on secondary tasks, avoiding the real work.  But, if my project is already started, I have no trouble picking up where I left off.  It’s the starting that bugs me.

I think I’ll try this little trick next time!

– newshirt

The trouble with tracking project time is that most people don’t know how quickly it passes.  Unless you are a geek who studies where project time is spent, you probably have little idea how quickly it rushes by.

Does that sound a little absurd to you?  After all, everyone from the day they are born, is conscious of time.  We live under its shadow every day.  So of course we all know how long things take to complete, right?

No… we don’t…  It’s like we’re willingly ignorant.  Nobody really wants to know how long a finished project will take.  I suppose this stems from impatience and aversion to hard work.  But there’s also a feeling that “the future” is infinite.  We really can’t see past the next few weeks, and a month (in project terms) is an eternity.

I always laugh when people say, “we’ll have that finished by [September].”  Supply your own month.  They don’t really have a clue, and don’t care either.  September is so far off, they can’t imagine it taking any longer.  The decision is purely emotional.  They can’t imagine is the key element in this scenario.  It’s not based on experience or logic, but rather the feeling that “future time” is next to infinite.  In other words, September will never come.

I’d like to know how you plan your projects…  Feeling or past experience?  Drop me a comment…

–ray

There is one trait of poor management that really irritates me.  Indecision.  I like a fast moving organization that makes decisions.  A long time ago, I read that AOL was like that.  Their managers made snap decisions and deals without any deliberation.  Too fast for the tastes of some.  Of course AOL/Time Warner didn’t turn out so well…

But lots of the companies I work with are paralyzed with indecision.  Here’s the kind of management I deal with all the time.

No… we couldn’t add the new Whiz Bang feature to the product because we needed Dan’s approval.  He was out on vacation until the end of the month, and had 10,000 spams to deal with when he returned.  Of course, we also needed Pam, Jim, and Joe’s input, but we couldn’t get them all scheduled for a meeting at the same time.  Joe was busy with Mary’s project, Pam needed to review the specs again, and I don’t think Jim likes me.  I’m not sure what the status is now…

Is it any wonder things don’t get done?  I don’t see any negative consequenses to indecision.  “Oh, you didn’t get the project done?  Oh, that’s okay…”  With a tightening economy, this don’t work.

My advice: if you are the manager of a project team, give your people the lattitude to make quick decisions - for good or for bad.  The cost of indecision is higher than the cost of mistakes - IMHO.

–ray

I really wish I’d thought of this one…  :)  (See the link below for PMI’s PM Network Magazine.)  Two project management auditors gang up on Wyatt Earp, demanding to know why he’s failed so miserably at the O.K. Corral.  They examine his project management methods and results, siting all kinds of iregularities.  Poor Earp has failed miserably in his famous gun battle, and he doesn’t even know why.

 Article by Michael Hatfield:

http://www.pmi.org/Resources/Pages/This-Month-in-PM-Network.aspx

The point Hatfield is making is this: sometimes you just have to go out with guns blazing.  Some projects just need to get done, regardless of what the experts say.  I’ve done enough all-nighter’s, 24-hour weekends, and three-day coding summits to know what he is saying.  The big showdown is sometimes what it takes to get the job done, and honestly, you feel like a gunfighter when the dust finally settles!

So, the next time your manager asks how you finished your project so quickly, tell him you went “Wyatt Earp” on it!

–ray

Yeah, I said it. Cut T.O. (Terrell Owens) from the Cowboys; give a pink slip to one of the best receivers ever. This guy argues with coaches, yells at his quarterback, and then complains to anyone who will listen. He acts like a punk. Imagine dealing with that on your project team! We’ve all been there, because project team dynamics are not much different. All it takes is one bad apple to bring the whole process down.

We look for individuals at the top of their game to help us win. The dichotomy is that sometimes these “all stars” bring a lot of baggage and pull teams down instead of taking them to the next level. Much of the time, people are misunderstood and their frustration builds, causing true problems. Remember the old adage, “perception becomes reality when left unchecked”?

What to do…the first thing I recommend is patience and a little communication. We aren’t babysitters, but we are dealing with people, not robots. A little attention goes a long way. The new coach of the Cowboys, Wade Phillips, is known as a “players” coach.  He takes time to learn about them individually and does not ride them too hard.  I thought Wade was soft and T.O. would run him over. Guess I was wrong. With Wade Phillips as coach, T.O. had one of his best years ever. The Cowboys started winning and have a team capable of going all the way. T.O. toned down his complaining and even won some praise from his teammates. Is it because Wade Phillips handled him like a China doll?  Who knows? I bet if they win a Super bowl no one will care!

As you can tell, I don’t like T.O. But right now my team, the Denver Broncos, could sure use his help!

–Warren

How long does it take you to launch a new product? Doesn’t it always seem to take 2-3 times longer than anticipated? I’ve been involved in the launch of over fifty new products, and it’s always the same routine.

We have a great idea, which seems so simple. If we take our existing product and just tweak it a little here and there, we can introduce something new. Simple enough, right? Wrong.

Products take an incredible amount of time to mature. A few tweeks suddenly turns into a handful, and then more. Current products need attention, drawing your resources away from the new one. Excitement wains when people realize the instant payoff won’t be there. This is turning into work… We never expected this!

I’d like to hear your project team experiences with new products, and new revisions. How smooth is it for you?

–ray

Have you heard of the “Optimizing Organizational Performance” webinar PMI is hosting?  It’s free, and the blurb looks good.  I’ve already registered.  Here’s the link below.

 http://www.amanet.org/events/optimizing-organizational-performance/

Here’s why you should attend:

AstroWix quote: Each year, an estimated $10 trillion is spent on projects around the world and almost 50% of them fail.

I’d like to hear your opinions, after the webinar.  What did you learn?  Was it over your head?  Beneath you?  Feel free to submit your comments here - that is, if you remember this blog posting after April 30th.

I personally don’t like heavyhanded project methodologies.  Anything heavier than a project plan, timesheet, and regular meetings bothers me.  I understand the need for process overhead, but sometimes people get carried away.  Of course, the simple approach assumes a top-down buy-in from upper management, something I always have.  Other organizations don’t have it so good.  So, let’s see how this PMI webinar works!

–ray