Posted on

Internal vs. External IT Support

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

Posted on

CIO: Are You Involved?

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

Posted on

Engineers Hide Risks

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

Posted on

Project Implications?

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

Posted on

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

Posted on

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

Posted on

Raising the Flag the Marine Corps Way

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

Posted on

How To: Create a Milestone in Microsoft Project

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

Posted on

Pathological Project Disease

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

Posted on

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