Archive for August, 2008

Aug 29 2008

DCAA Compliant Projects

Published by warren under Advice

Are your projects DCAA (Defence Contract Audit Agency) compliant? Maybe you have never heard of this term or perhaps you have never worked with a government contract. In any case, for many people it is highly likely that some day you will. 

Becoming DCAA compliant can be a daunting task. It requires some very general rules on some items and is very specific in most areas. There are guidelines on how to submit proposals, how to track work on those proposals, and it even mandates internal procedures to comply with the DCAA’s rules and regulations. It is so steeped in red tape that there are nearly 100 classes offered on DCAA compliance training. I would not dare bore you with all of the details here, but it is worth noting that consultants/accountants are available who specialize in this field. However, be warned, they are not cheap. 

In addition, there are time keeping/project management tools available like Standard Time that support project efforts to become DCAA compliant. There is a sizable market in government contracting and a nice cottage industry for consultants that specialize in government contracts.  The moral of this blog is take advantage of the expertise available to avoid having to sit through 70-80 classes on DCAA compliance.

–Warren

No responses yet

Aug 27 2008

How To: Resource Allocation in Standard Time

Published by raywhite under How-to

Resource allocation in Standard Time®is very straightforward, mostly because ST does not have the complex scheduling capabilities of Microsoft Project.  The image below shows a (compressed) screenshot of the resource allocation window.  We’ll discuss how to display and manage task allocations.


Standard Time Resource Allocation Window

 First, you should realize that the bars represent hours worked in a time period.  The resource allocation window collects all tasks assigned to each employee, and assembles them into time periods based on their starting dates.  If you have ten tasks that all add up to 80 hours, you might see two bars, one for each week.

The red bar in the image above represents a over-allocated week.  That means you have too many tasks to be performed in a single week.  Yellow bars indicate to little work (or under-allocation).  Blue bars are just about right.

Simply create new project tasks and give each one a starting (and optional due date).  When these tasks are assigned to employees, the resource allocation window shows them split up into time periods.  That’s about all you need to do!  It’s pretty simple.

–ray

No responses yet

Aug 26 2008

Define: Make Verses Buy

Make verses buy: The act of building a product for your own internal use as opposed to licensing a pre-existing product.

 

Organizations with the ability to produce their own products are often tempted to build everything, including the tools they use.  This is most common with software companies.  They have a bank of software developers, some sitting idle awaiting jobs, and the company is tempted to use those resources to build all the tools they use.

I once worked for a software company that wrote their own compilers and debuggers.  For internal use only.  Yikes!  When Microsoft sells compilers for less than a thousand bucks, this doesn’t sound cost effective to me.

Again, the temptation usually stems from developers sitting around on their hands with nothing to do.  Why not put them to work building internal tools?  My opinion: bad idea - almost every time.  Those developers are saving the company very, very little money.  After all, off-the-shelf software is cheap.  So, divide the number of hours they work by the cost of the software, and your developers are only making a dollar an hour.  Better to put them to work in customer support or sales, cold calling for gigs.

The real killer comes when the software they wrote needs bug fixes and maintenance.  Are those same developers still available?  Usually not.  So who pays for the bug fixes?  You.  Was it still cheaper to write your own stuff?  I doubt it…

 

–newshirt

No responses yet

Aug 25 2008

Define: Effort Driven Scheduling

 Effort driven scheduling: Calculating project task duration based on assigned resources.

 

When you assign resources to a project task in Microsoft Project, it recomputes the ‘Duration’ field.  The screenshots below illustrate this.  We’ll begin with plain tasks with no resource assignments.  After creating the tasks, we’ll assign the first resource, and then all the rest.  We’ll show that the ‘Duration’ column is changed when more resources are assigned.


Tasks with no resources assigned

 

Why does Microsoft Project recalculate the ‘Duration’ field when new resources are assigned?  The ‘Duration’ column indicates the calendar time that will elapse as the task is being completed.  That may be different than the ‘Work’.  If more resources are added, the calendar duration will go down.  That is effort-driven scheduling - based on employee effort.

 


One resource assigned

 

A magical thing happens when we assign multiple resources to tasks.  Notice that the ‘Duration’ column is reduced to reflect the extra effort applied to the tasks.  Since the tasks are effort-driven, they require less calendar time to complete.

 


Effort-driven task scheduling

–ray

No responses yet

Aug 22 2008

Overdraft Protection For Project Management

Published by warren under Advice, 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

No responses yet

Aug 20 2008

Advice: Develop Products for the 98%

Published by raywhite under Advice, Product development

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

No responses yet

Aug 18 2008

Where My Ladies At, Yo?

Yo, dog…  Where my ladies at?  Got me a grip a cash an’ a HP blade.  I’m a IT professional!  But where my womens at, yo?

I’ve decided to convert this blog to attract the hip hop community.  Especially those from the IT industry.  How am I doing so far?  No, really, I’m just wondering where the fine ladies are at in the IT industry.  Coders, network admins, dbo’s, project managers.  There’s only one for every four men.  That’s right, about 25%.  Check out the links below.

http://www.cioinsight.com/c/a/Past-News/Numbers-Show-Big-Decline-of-Women-in-IT/

http://news.zdnet.co.uk/itmanagement/0,1000000308,39352947,00.htm

 

I have my own theories about the disparity in numbers…  To me, the ideal IT employee nests in the server room amongst the network cables, routers, and modems.  He beds down with a blade under his pillow - an HP server blade that is.  Occasionally - usually on a full moon - he emerges to shower, change his crusty socks and underwear, and prowl for chicks at the all-night gaming bar.  He writes a staggering mountain of code, making dark hackers look like kiddie scripters.  In past lives, I was that foul-smelling geek - so I know.

Now,,,,,,,,,,,,,,,

Show me a girl who wants to live like that.  Sure, I’ve seen lots of nice professional women in the IT industry.  They wear nice professional suits, and make their hair up in nice professional styles.  They’re nice.  Professional.  But they don’t “live” for the bits.  In my 25+ years in the biz, I’ve never seen a true geek chick - one who codes until her eyes run and sleeps under her monitor.  (Yes, I’ve actually bunked under my computer desk, and so have some of my friends.)

Once an IT department gets a few guys like that, they don’t the respect the “nice professional” types.  I’m sorry for the crude characterization (and maybe I’m dead wrong), but passion for the bits still sells, not professionalism.

 

Peace Out,
–newshirt

No responses yet

Aug 15 2008

Internal vs. External IT Support

Published by warren under Business

There has been a lot written in the past few years about outsourcing technical support and SaaS (software as a service). It is not an easy choice for a company to make. On one hand, dumping all of your IT issues on someone else may save a few dollars and headaches.  On the other hand, you do not always have control over the type of support your company receives–costing you more in the long run.

While many companies are using SaaS, many other companies do not. It is easy to get caught up in the latest trends, but trends are just that, and they are not always permanent. I have had the priviledge to work with a lot of major U.S. companies and while I can not say whether outsourcing is a true fad or not, I can tell you, imperically, that 75% of my contacts keep everything in-house. So do not be swayed by all of the tech media and exposure of recent trends. There is a place for both internal and external IT support. I guess it all comes down to cash flow: which one can I afford right now, and which one will be better in the long run?

 

–Warren

No responses yet

Aug 14 2008

CIO: Are You Involved?

Published by raywhite under Uncategorized

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

No responses yet

Aug 13 2008

Engineers Hide Risks

Published by newshirt under Project failure, Project teams

Every project manager knows he must identify project risks, document them, and resolve each one.  In other words, he must learn what could jeapardize the duration, budget, or quality of his project.  If you don’t, the project may fly off the tracks and you’ll look bad, or worse.

Problem is, your engineers are hiding those risks from you.  The fictional dialogue below shows how it happens.  It is a faux conversation between your project manager and one of the engineers on the team.

PM: “I love your new designs!  This project is really coming along.”
Eng: “Uh-huh.” (hoping to be left alone.)
PM: “Do you think you’ll be finished by October.  Big deadline you know!”
Eng: “Of course.” (barely lifting his head.)
PM: “Any risks or unknowns?  How about that integration task?”
Eng: “Nothing I can’t handle.” (peering deeply into the montor.)

Engineer-boy has two problems.  First, he’s a little too independant to admit he needs help.  Secondly, he won’t risk the tarnish to his stellar reputation.  No white-shirt, tie-bearing, non-pierced PM will ever get him to crack.  He’ll work all-nighters if he has to, or so he tells himself.

 

–newshirt

No responses yet

Aug 08 2008

Project Implications?

Published by warren under Uncategorized

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

No responses yet

Aug 07 2008

Define: Resource Allocation

 Resource Allocation: The assignment of project tasks to employees over a specified time frame.

The chart below (taken from Standard Time®) shows an example of tasks allocated to one employee over three months.  The blue bars are correctly allocated time.  Yellow means there are not enough tasks, and red means there are too many.

So what does ‘correctly allocated time’ mean?  It means that a project manager has lined up project tasks for an employee to work on, but has not given too many or too few.  There are ‘just enough’ for the employee to complete in a given time.  The 63 hour week below is as unworkable as the 10 hour week.  Anything within 10% of a 40-hour week works.

 


Resource Allocation Chart

 

–ray

No responses yet

Aug 06 2008

Advice: Create Layered Products

Published by newshirt under Advice

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

No responses yet

Aug 05 2008

Raising the Flag the Marine Corps Way

Published by raywhite under Project teams

I picked up a neat little business management book named “Semper Fi, Business Leadership the Marine Corps Way.”  The web address is below, in case you’d like to check it out.


http://www.semperficonsulting.com/

The philosophy of the book is to run your business like the Marine Corps.  Does that mean scream bloody murder into the faces of your new recruits?  Only if they need it.  :)  No, it simply outlines the Marine Corps way of running its operation and the parallels to business management.  Here’s a quote from the book.

In Officer Candidate School, there is a famous exercise in which the prospective officers are given the assignment of raising a flag pole so that it meets a number of detailed specifications.  It is assumed in the exercise that the officer has one sergeant and two privates to assist him.  The instructors are constantly amazed at the ingenuity of the trainees, who have come up with a thousand and one ways to erect that flagpole.  What the instructors are looking for, however, is a much simpler answer: “Tell the sergeant to raise the flagpole and walk away.”

The point of the exersize is to delegate to subordinates.  The sergeant can figure out the details on his own.  And, if they are very detailed, he can present his plan to the officer before proceeding.  This leaves the sergeant to get the job done, and the officer free to strategize the next steps.  Everyone has his job to do, and things move efficiently.

 

–ray

No responses yet

Aug 04 2008

How To: Create a Milestone in Microsoft Project

Published by newshirt under How-to

Milestones are a necessary element of project planning.  They let you stop and evaluate.  Have the objectives been met so far?  Is everything ready to proceed to the next step?  If so, we have achieved a milestone event, and the next phase can begin.  Here’s how to create a milestone in Microsoft Project.

Start by creating three tasks.  Notice that the third task is a zero-duration task.  That is considered a milestone in MS Project.  We’ll be linking into this task so that it gets pushed out if any other tasks go longer than anticipated.


Milestone Task in MS Project

 

Select tasks to link them.  CLick in the selection column to select an entire row, then Ctrl+Click in another row.  Click the Link button to link them.


Selected Tasks

 

Link and move some to illustrate the milestone.  Here we see both tasks linked into the milestone.  If either task is delayed, the milestone will be pushed out.  When the milestone date arrives, you should evaluate your project to make sure it is on track.  Then you can proceed to the next phase.


Linked Tasks

One response so far

Aug 01 2008

Pathological Project Disease

Published by warren under Project failure

Nothing slows a project team quite as well as a pathological scenario or a person focused on that scenario. There is a huge chasm between the due diligence of “what if” questions that are likely possibilities worthy of consideration and the terminal scenarios that will, more than likely, never happen. The goal as a Project Team leader, or any manager for that matter, is to quickly separate the two and move on with the real issues. Too often, equal time and weight is given to both scenarios.

In fact, that nearly happened to me this week. I spent about 2 hours in a meeting discussing various topics and questions when a pathological expounder forced the whole group to spend 20 minutes on a crazy “what if” scenario. This leads to critical slow downs and ultimately analysis paralysis. I was lucky  to defuse this situation before it ate up the whole meeting. 

So, the next time someone asks a “what if” question, ask a few of your own. How likely is this? What is the foundation for the question and what is the impact? By asking these simple questions you will force the person to evaluate their questions more clearly which removes the emotion and fear that typically drive these issues. Now, you have given logic a chance, which gives your projects better focus and makes them more likely to succeed. Any questions? 

 

–Warren

No responses yet