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