Overdraft Protection For Project Management

Many banks offer overdraft protection for their customer’s checking accounts. It could be for an attached savings account, a small line of credit, or another mechanism designed to cover any over-runs on your checking account. After all, mistakes happen. This is a little insurance policy you may never use, but it is better than paying large overdraft fees.

So, why on earth are we talking about this in a project management blog?

Well, it is simple. Do you have any protection against project budget over-runs?  Any last line of defense?

A main part of a Project Managers’ job is to successfully finish a project on time and under budget. With all of the variables involved, that is a tough proposition! For help with cost over-runs you may consider a tool like Standard Time®. Standard Time contains an automated feature that sends warning e-mails when a task or project is nearing the intended limit. In addition to the warnings, a Project Manager can set a “no pass” limit that will prevent an overrun or an allowance, but only if the Project Manager/Administrator allows it.

Task Warnings in Standard Time®

Nothing is fail safe. However, Standard Time is one tool that identifies impending problems and may be the extra nuance that keeps your projects on track.

–Warren

Advice: Develop Products for the 98%

Here’s some project management advice: And I’m going to complain a bit…  Hope you don’t mind.  🙂  I notice user interface design – especially in software products.  I notice menu placements, dialog box layout, screen widgets, and everything else.  And there’s one thing that always bothers me.

    Complex products seemingly designed for 2% of the intended users – %*^$*#

Developers fall into a common trap: adding too many menus and screen gadgets.  Here’s how it happens…  Sales managers, product managers, and CEO’s all want products to do something new.  Something big and flashy.  Something they can sell.  So, they call down to the developer’s cubes to make it happen.  And it does!  Unfortunately, so do dozens of other feature requests.

Developers often don’t know how to bury the obscure features and highlight the common stuff.  Everything is given equal weighting in the user interface.  That’s okay until you have a hundred big features.  And then everything runs together.  Users see so much stuff, they can no longer gear the product to their own purposes.  It takes a Masters degree to figure it all out.

A better approach is to develop the product for the 98% of customers who will use it.  In other words, MAKE IT SIMPLE!  Bury the features intended for the other 2%.  That doesn’t mean you’ll only bury 2% of the menus and dialogs because normally about 50% of the product falls into the “obscure” category.  Bury all that, and explain it to the 2% who need it.

 

–ray

Advice: Create Layered Products

Project management advice: Create layered products that allow you to release new updates once a month.

 

I was originally planning to title this post ‘Create foundational products’ and then I quickly realized that the foundation is only the first layer of this strategy.  I’m advocating short, quick releases, in layers.

I’ve found that big, monolithic product releases have several downsides.  They are often riddled with bugs and usability issues, and sometimes require several slipstream releases to resolve all the bad stuff.  Developers bite off more than they can chew, and the product becomes so complex that complete testing is not possible.

Small, frequent releases solve this problem.  With each release, you have the opportunity to fix prior bugs and advance the grand design a little further.  True, you can’t toss out your ‘take over the world’ design in one giant release, but given some patience, you’ll get there.  And the product will be a lot more solid when you finally reach that point.

Start with a simple foundation.  It probably won’t have all the features customers are screaming for, but it gets you started.  Follow up with several small releases that fill in the gap.  Listen to beta users and customers, and build the grand design with their input.  Trust me, you’ll be a lot better off in the end.

 

–newshirt

Advice: Track Project Time

Project management advice: Track your project time.

Organizations perform projects for a lot of reasons.  Consulting companies perform the same projects (often with small changes) for every customer.  Manufacturing and engineering companies build things, requiring complex engineering projects.  Government organizations perform IT and data processing projects.  Every one of these can benefit from tracking project time.

Whether you use a timesheet or computer-based timer, tracking your time provides several advantages.  Some managers have no real idea how long their projects take.  They have a gut-feeling, but no hard numbers.  And trusting your gut only works when steeped in actual numbers from the field.

No more guessing
WIth actual numbers behind you, there’s no need to guess.  You have the hard facts, and they cannot be disputed.

Accurate finish dates
Assuming you have have performed a similar project in the past, setting a finish date will be a no-brainer.  You’ll have details to back up your outrageously long schedules.

Concise records
This is crucial for consulting companies.  Client billing depends on accurate numbers to back up your invoices.  But manufacturing and engineering groups also need good records to back up their project cycles.  In the end, clients and managers want to know what you have been up to.

 

–ray

Advice: Have a Project Champion

Project management advice: Every project needs a champion.

It took me a while to understand the nature of product development and the need for project champions.  At the beginning of my career, I believed projects just “got developed.”  I was working in a research department at Eastman Kodak Company, building cutting edge photocopiers.  Engineers buzzed around, building microprocessor-based circuits, image-enhancing emulsion, and writing software.  I did my part and just expected the product to come together.  Looking back, I now realize there was one man who made it all happen: a gray-bearded old dude who wanted to change the industry.

Products get developed, and projects finished, only when there is someone with the burning desire to see it happen – like the old bearded dude in the example above.  A paycheck is not enough.  You have to want it badly.  Only then will you fight through all the obstacles to make it happen.  Projects often take 2-3 times their original estimates, and some required several iterations to realize the full glory.  And only a true champion will endure the suffering to see it to completion.

Look around at your project.  Do you have a champion?  A person who refuses to give up?  If not, you have good reason to fear that the project could be canceled or back-burnered.  Have you personally ever been a project champion?  If not, give it a try.  Throw yourself into something that really engages your passions.  You’ll find there’s satisfaction in a job well done.

 

–newshirt

Advice: Get Corporate Buy-in

Project Management Advice: Get Corporate buy-in for your projects.

In other words, make sure the corporate executives are active stakeholders in your project.  I suppose this goes without saying, but I’ve seen lots of projects where this is not the case.  Project teams somehow come to the conclusion that their project will be funded and accepted, even though corporate has not explicitly said so.

Just because your team is developing a new product or in-house tool, doesn’t mean corporate will stand by you.  Without vested stakeholders at the highest level, your project could easily be canceled.

The name “Harold” comes to mind when thinking of this subject.  I worked with a man named Harold who was researchinig a product for his company.  Months went by as he studied the features and benefits.  He eventually took a job with another company and I discussed the project with his boss.  His boss said he never knew what Harold was up to, and had no intention of adopting the product!

 

–ray