Project Management article in CoBizMagazine.com

Last month, our Project Management Instructor, Chris Bart published an article with cobizmag.com on Project Management for non-project managers.

Ask trained Project Managers how they most effectively manage, and they will give you variations on the same theme: the tools of professional Project Management. Unlike any current management fad, the tools of Project Management have been around for decades. In fact, the most commonly-used tool is over 100 years old! These tools have endured because they work.
– Chris Bart
Read more...
Learn more with our Intro to Project Management Class.



 


What is Situation Management?

By Chris Bart

See our SITUATION MANAGEMENT CLASS on April 13.

Does it seem that you and your team keep getting blindsided by circumstances beyond your control, or outside the bounds of your department or Project? Consider this manager's predicament:

It all looked so promising. The Project had a quick, exciting launch. The client was enthusiastic, the team was ready to go, and the Goal seemed clear. Just a few short months later, all had shifted. The client was angry, the team was demoralized, the Project was mired in details and nobody seemed to know what "done" looked like.

Worst of all, this was beginning to seem familiar. The manager had always prided themselves on being the "go to" person, the one depended upon to "tough it out" when needed. Now, once again, all had gone astray.

Why was the department team so down? Was it a sense that they were helpless, that they had no control over their Project's destiny? They found themselves sinking deeper into dark feelings, less and less capable of moving forward.

The manager asked: Might there be some fundamentally different approach that would help avoid this in the future? Many had suggested finding a Problem or Goal and setting a Project to attain it. Unfortunately, that was just what had led to the current predicament.

There had to be other factors (or Arrows, as they came to be called) to be considered first. One manager pointed out that only a fool would attempt to manage without getting information first. This made good sense. Information – the Data Arrow – was always first.

The next in the sequence was the Risks Arrow. Before Problem-solving, we need to assess Risks. A cop may be called to address a possible burglary Problem at a business, but she had better get information (the Data Arrow,) such as whether she is wearing her body armor and has adequate fire-power if she is to address the Situation.

As the manager considers Risks, they may need to loop back up to obtain still more Data. This was another key message from the most successful managers. They looped through the Arrows one level at a time, until they were prepared to go down to the next Arrow in the list.

With Data and Risks addressed, top-performing managers look at Problems, because a Problem is a Risk that has already occurred. After gathering enough Data on Problems, the manager can move to Decision-making, looping back up to Data and then down through the Arrows as needed.

A key Decision is the creation of a Goal. Remember Goals? That was where we wanted to be, so we could start a Project to attain the Goal. With a thorough analysis and processing of the first four Arrows, we can now proceed.

All managers always need People and Communications. Taken as a group, these eight factors came to be known as the Arrows of ZengWay, which is the system of Situation Management.

  • Data
  • Goals
  • Risks
  • Projects
  • Problems
  • Communications
  • Decisions
  • People

It occurred to the manager that these eight factors were everything needed to manage. The realization hit home that up until that moment they had been reactive, more fire-fighter than manager. As such being knocked off track to attaining Goals was predictable. The manager became determined to be one of those people they admired — a Situation Manager.

Do you want to learn more about how to become a Situation Manager? Join our next Situation Management Training Class on April 13, 2012.





 


Microsoft Project 2007 Eliminating Automatic Constraints

Why do I see constraints on some of my tasks, even though I never set a constraint?

Microsoft Project sees any task with a "hard coded" date as a constrained task. This means that if you type in the start or finish date for a task, you are effectively setting a constraint on that task. This can be a problem if you have a delay in project that SHOULD cause a task to be rescheduled – because the constraint will prevent this from happening.

Microsoft Project Automatic Constraint

The solution is to avoid typing in dates! Use predecessors and successors instead.





 


Project 2007: Creating Constraints

Remember: constraints are to be used very sparingly, if at all! But sometimes you need to constrain a task because of a delayed shipment of supplies or for another good reason. For example, let's assume that the paint color for the final coat of your project will not be available until Monday, January 19. Here's how you set this constraint:

  1. Double click the task name to open the task information box
  2. Select the Advanced tab
  3. Use the drop-down chevron next to Constraint Type to choose a hard or soft constraint
  4. Select the appropriate date for your constraint
  5. Click OK
  6. Your results should look like this.





     


Microsoft Project Constraints and Predecessors

I keep hearing I shouldn't use contraints in Project unless I have to. Why is that?

A constraint (or a constrained task) in Microsoft Project is a task that has its start or finish date "hard coded" into the project plan. This means that the start or finish dates of the task won't change no matter what – even if it should. This can be a problem if you are running behind on certain tasks in your project, and therefore are not able to start subsequent tasks that depend on the task running late.

Microsoft Project Constraints

For example, let's say you are painting the living room in your house, and you expect it to take 2 days to get done with the first coat – but it actually takes three days instead. This means that the new start date for the second coat needs to be delayed by a day – but using a constraint would prevent this from happening!

In some cases, constraints are necessary and useful. Learn to add constraints in Project with our other post.

Predecessors in Project

The solution is to minimize (or eliminate) the use of constraints – and use predecessors and successors instead. If we link the First coat and the Second coat by the use of a predecessor, the second task is then free to reschedule if the first task happens to take longer.