Posted by: Craig Harding | October 21, 2009

What is the Project Manager’s Role in Assigning work?

What is the Project Manager’s Role in Assigning work?

Once you have broken your project work down into tasks, estimated the time it will take to complete them and identified who is on the project team, you’re ready for another key PM responsibility. You must ensure all tasks are assigned to specific individuals on the team. In many cases, some or all of the core team will have been assigned to the project at the same time you were. If it is a small project, there will be few decisions about who will do what task – there will be only one person with the capability. In larger projects you may have some choices to make about who is assigned what work. Even if task assignments are a forgone conclusion, you are still responsible to ensure every team member knows what his or her task deliverables are, what the scheduled start and end dates are, and how many hours are allocated for each task.

One of the tools you can use to communicate work assignments is a “turnaround” document. This is really an excerpt from the project plan that shows the schedule of all tasks for an individual resource. If you are using MS Project, there is are several automated reports that can be used as a Turnaround document. If you are using an Excel spreadsheet, you must produce a report or table that contains the rows specific to an individual resource. When you prepare a Turnaround document for each team member, it should include pre-printed columns showing:

  • The resource name and the group (e.g., Client or consultant, HR or Payroll team)
  • The date of the data contained in the document and the date the document is generated
  • A task reference number that will map back to the overall project plan
  • A listing of the tasks assigned to the resource
  • The estimated effort for each assigned task,
  • The scheduled start date

Once you have taken a first pass at the work assignments for your team members, distribute the Turnaround documents and schedule a planning session with each team member. As the PM, you should ask individual resources to confirm their assignments in view of the skills or knowledge required. Additionally, the resource will review and perhaps adjust task estimates based upon his/her confidence level of information available. Once the tasks and assignments are confirmed, you will establish a baseline or “Point-in-Time” schedule. Subsequently you will compare project progress against this baseline to monitor and report slippage.

The Turnaround document can also be used as a means for tracking progress of assignments. Project Team members submit their updated Turnaround document weekly. Therefore the document should also include preprinted columns with blank fields for:

  • Actual Start and Finish Dates
  • A field for the team member to enter the total hours charged to the project for the week.
  • A filed to record hours of work remaining on each task.
  • A free form field for comments or other feedback

When you need to Assign Work

Work assignments are made in conjunction with the development of the baseline project plan. As soon as you have developed the WBS and added time estimates, you should assign generic resources (e.g., HR Functional, Benefits Functional, Tech, etc.) for all tasks. Before assigning any real resources you should first complete the schedule based upon the relationships between the tasks. This will give you a schedule based on the order in which work physically has to be done. Once this has been done, you can identify specific resources and start looking at the schedule impact of adding those resources. You should substitute actual names on your plan and prepare Turnaround documents for the resources you have. In some cases, your team members will already be on-site when your plan is developed. In other cases, you will need to work with Staffing or with your client to obtain specific resources. When this is the case, develop the Turnaround document as soon as the specific resource is available so that no time is lost in making work assignments.

Your Role in Assigning Work

As a PM, you need to assign work appropriately. You should plan work assignments to meet three goals:

  • Maximize project effectiveness in terms of schedule and quality,
  • Ensure the team has credibility with the client, and
  • When possible and practical, provide developmental opportunities for newly-hired consultants.

At times, these goals can seem to conflict with one another, but the key is to keep the demands in balance by making conscious decisions about the trade-offs at every step.

You are responsible to:

  • Provide a copy of the project plan and a Turnaround document for each resource to make sure that assignments are communicated (and documented).
  • Check with resources to make sure that assignments are clearly understood by project team members and that they can commit to what you’ve articulated they will do in the amount of time you’ve allocated for it.

This means that it is your responsibility to do the initial planning of work assignments. Then, it is your responsibility to clearly communicate those work assignments in a manner that builds trust and openness within the team. You should be open to input from your team on these initial work assignments and be willing to make mutually agreed-upon changes based on the feedback you get from your team. As a Project Manager, you are responsible to inform team members what they are expected to do, but not how they are expected to do it. After any initial modifications have been made, you are responsible for tracking each team member’s progress on each of their deliverables.

Changes in the Project

When changes are made during the project (either through the Change Control Process or as a result of updating and refining the operating plan), you will need to assign any new tasks to a resource. Or a resource may leave the project for one reason or another, and you will have to assign work to a replacement. You will need to inform the team member(s), update the project plan, and issue a new Turnaround document to the resource in question.

Other Project Tasks

Inevitably there are tasks that don’t clearly fall in to the specific expertise of one resource or another, and you use these situations to make assignments that balance workloads, maximize working relationships, provide resource development, etc. For example, developing an Acceptance Test Plan or working with clients on test scripts can be done by any of the functional resources, so you could assign these types of tasks to one whose workload is lighter than another.

Mistakes to Avoid

There is one class of tasks you should never assign to another member of the project team: the tasks of project management. It can be very tempting to assign administrative tasks to others. However, a PM should never delegate away the responsibility for updating the Project Plan. Project Managers are expected to enter any updates to the Project Plan themselves because the process of updating the Plan requires making judgments about the work. For example, if a team member submits a revised target date for their work the PM must evaluate the situation. Why is the target date shifting? Is there a legitimate reason or is there a productivity problem that must be addressed? What is keeping the resource from making the progress expected? What is the impact of the revised target date on the rest of the project? A Project Manager cannot delegate the accountability or the responsibility for updating the project plan.

It is sometimes appropriate (and this takes good judgment) for a PM to delegate responsibility for some tasks that are considered “project management.” For example, developing a communications plan, or setting up an issue tracking system, or putting together the Charter. However, you cannot delegate the accountability for that or any other PM task.

It is unwise to assign even the responsibility for doing the task to a team member unless you have a large project, and both you and the resource know exactly what you are doing. One reason is that you have full accountability to maintain control of the project, and you have to really know what is going on in all aspects. Another reason to be sensitive is that you are actually assigned the PM work and clients are billed for you to do it, while other resources are billed to do specific functional or technical work. Team members really shouldn’t have gaps in their workloads that would allow you to offload work to them.

On the other hand, Project Managers may be tempted to do work that properly belongs to others. Many PM’s have difficulty keeping their work separate from their people’s work. In the Course Introduction you read about the common confusion that inexperienced PM’s have about their role. Many PM’s still want to play a technical or functional role on the team. You will often feel pulled to do your old job. If you give in to the temptation, you will jeopardize the project.

To summarize, project work assignments must meet the following criteria:

  • The work assignments for each team member are “complete,” i.e., contain a list of all tasks and success criteria such as:
  • expected target dates
  • estimates of work effort
  • a way to reference tasks back to the comprehensive work plan so that such information as task dependencies and supporting resources can be determined.
  • Project Management tasks have not been delegated to team members
  • Overall there is reasonable alignment of skills to tasks
  • There is no avoidable imbalance, with one resource scheduled to work long hours and another with a very light load.



Posted by: Craig Harding | October 14, 2009

How Do You Manage Conflicts as a PM?


Conflicts can arise at any time in a project. In fact, they are common. What is uncommon is the ability to deal with conflict and to resolve it competently. Generally this is because we tend to hold misunderstandings about conflict; and these misunderstandings prevent us from developing conflict management skills.

For example, many people strive to avoid conflict at all costs. As a result of this mindset, we don’t actually avoid conflict, we merely delay recognizing and dealing with conflict until it turns into a crisis that can threaten the project. The key is to recognize conflict early and deal with it effectively.

There are several important things to keep in mind about conflict:

  • Conflict is not necessarily destructive; it can be a positive force for change. Therefore, to manage conflict effectively, it helps to have a positive attitude toward it. Conflict is really opportunity.
  • Conflict usually occurs when people’s needs are not being met.
  • Conflicts are most likely to arise on a team during the “Storming” Phase. The Project Manager can best respond by clarifying roles and providing support.
  • The key to recognizing conflict early is to develop your sensitivity to the signals of conflict. A sense of discomfort or tension; specific, unsettling incidents; and misunderstandings are all signs of underlying conflict. A conflict left hidden and unresolved for too long can result in a crisis.
  • The way to get control over conflict is to a) Take a creative response to it and b) Aim for mutual gain.

When you need to Manage Conflicts

There is a window of opportunity that begins as soon as the signals tell you that a conflict may be present—and before these incipient conflicts become crises. This can happen at any point during the project. It is an important and ongoing responsibility.

Your Role in Conflict Management

As a project manager, it is your responsibility to resolve conflicts to maintain a positive and productive team.

When a resource creates conflict on the project, you must meet with the resource to seek a constructive resolution. When you do so, it is important to:

  • Do your homework and collect pertinent facts in advance
  • Listen to the resource,
  • Observe behaviors
  • Understand the issue from all perspectives, and
  • Focus on what can be done to improve the situation

You may sometimes have to manage conflicts with the client project lead, for example:
The team lead may feel obligated to support the client team members even when they are wrong. Keep in mind that the client team members were likely a team before you arrived on the project and you may find your project team pitted against the client team. It is the responsibility of the PM to remain objective and resolve issues based on facts rather than feelings.
This may involve delivering bad news to the project lead’s boss (to the best of your ability avoid affecting the project lead’s career).

If the agreements made for resolving the conflicts will have an impact on project deliverables, time, or budget, remember to use the formal Change Control process before making commitments that will change the project plan.

If a conflict is very large and involves policy or an irreconcilable difference over standards and goals, you may want to involve the project sponsor or steering committee. For example, if you learn that this conflict is stemming from the client’s suppressed feeling that the system is not a solution for their department; the best thing to do is to contact the sponsor.

If the conflict continues

Unresolved conflict should be handled (documented, tracked and managed) like any other issue/risk, unless the project becomes stalled. If that happens, as the PM you must contact the sponsor so that appropriate actions can be taken. It is very important that you first do your utmost to address and resolve the conflict before it reaches such an impasse. You don’t want to be in the position of taking a long-standing conflict to your sponsor, and having to explain that you have not yet made any attempt to resolve it yourself.

Acceptance Criteria for Conflict Management

Projects suffer when conflicts arise but are not addressed and resolved. For consultant project managers you want to meet your contractual obligations, but also want a good reference from your client. Unresolved conflict may prevent a good reference even if you meet other objectives. You will have done an excellent job of conflict management if you:

  • Identify a conflict early and determine what potential it has to jeopardize the project
  • Identify the key needs and concerns (interests) of the parties involved and where they overlap.
  • Explain how the conflict will affect the project if not resolved, and back this up with evidence (contract, SOW, status reports, or whatever is relevant).
  • Address the conflict situation with the parties involved and get agreement on a course of action that:
  • meets some key needs of all parties, and
  • removes the project from jeopardy
  • Follow up to ensure the problem is resolved, and if not, take further action.
  • Apply issue management as appropriate (don’t document a personality conflict, document slipped schedules or disagreement on task completion, etc.)
  • Any conflict situation
  • Your common sense, sensitivity, and detective work
  • SOW/scope definitions, contract, etc.
  • Status reports, turnaround documents, and other specific data.
  • Issue management and change control process as needed

Inputs to Conflict Management

Remember, all projects have conflicts of some form or another. As project manager it is your responsibility to remain objective and resolve issues to the best of your ability based on facts rather than feeling.



Posted by: Craig Harding | October 6, 2009

Progress Tracking Methods in MS Project

Progress Tracking Methods in MS Project

Over the last couple of weeks, I have had several people ask me “what was the best way to track progress with MS Project or on projects in general?” There are a couple of methods of tracking progress that is normally followed; the method you choose will depend on the level of rigor or accuracy you have decided on for your project. These are:

  1. Percent of work complete
  2. Hours of work done per period on each task
  3. Actual work done and work remaining

Percent of Work Complete

For this progress tracking method, you would ask the resources to report the percent of work complete on each task. It is extremely important that everyone is clear on how you measure percent complete. Often the team will agree upon levels of completeness depending on the types of tasks. For example, development tasks could be 50% complete after coding, 75% complete after unit testing, and 100% complete after moved to user testing environment. Whichever way you measure percent complete, be sure to be consistent and that all team members understand and agree to the metrics.

The drawback to this method is that it does not completely represent the progress of the tasks. You do not get an accurate measurement of time spent on specific tasks. You are also not able to account for an early or late finish as you don’t have a real good picture of the work remaining on the task.

Hours of Work done per Period

Another method of tracking progress is by collecting hours of work done per period on each task. Here the resources will report the hours worked on each task over the period and you record hours directly into MS Project against each task. This method will allow you to track actual hours against a task compared to the relative planned (baseline) hours. This will give you a sense of whether or not tasks on schedule. However, as with the percent complete method, you really don’t get an accurate picture of early or late finish times on tasks as you do not know how much work is remaining on any one task.

Actual Work and Work Remaining

The most accurate method of tracking progress is using actual work done and work remaining. With this method, each resource reports the actual work done and the work remaining on each task. Now you are able to track the number of hours worked relative to the planned hours, plus you know the number of hours needed to complete the task. This work remaining is then used to calculate the new finish date of the task which can be earlier or later than the baseline finish date. Now your plan is more accurate and you are able to deal with scheduling questions on a plan that more closely reflects reality.

The level of rigor you apply to tracking your project’s progress will often depend on the several factors such as project length, project priority, project budget/time/resource constraints. So choose the method that best suits your project guidelines and stakeholders expectations, keeping in mind the accuracy of each method.



Posted by: Craig Harding | September 30, 2009

How to Visually Track Progress in MS Project

How to Visually Track Progress in MS Project

The old saying that a picture is worth a thousand words can certainly be applied when tracking progress in MS Project. A clear visual cue of how tasks are tracking compared to the baseline can be extremely valuable for identifying trouble areas at a glance.

The following figure shows an example of using visual indicators (Stop Lights) to indicate if tasks are on schedule, slipping, or behind. Green indicates the task is on schedule, yellow indicates the task is 1 day behind, while red indicates the task is 2 or more days behind schedule.


To set this up in MS Project you first have to create a custom field to analyze the progress. The steps are as follows:


  • Click View | More Views, Select Task Sheet, and click Apply
  • Click View | Table: Entry | Tracking
  • Select Tools | Customize | Fields.
  • Choose Duration from the Type drop-down list.
  • Ensure that Duration1 is selected then click Rename.
  • Type the name Days Behind and click OK.
  • Click Formula, select Field | Date | Start Variance, and click OK, then OK again when prompted.
  • Click the Graphical Indicators button then use the chart below as a guide on how to configure the options in the dialog box. You will have to type in the values 0d, 1d and 2d.
  • Click OK to close the Graphical Indicators dialog box.
  • Click OK to close the Customize Fields dialog box. 
  • Right-click the Act. Start column header and select Insert Column.
  • Select Duration1 (Days Behind) and click OK.



Personally I find it much easier to quickly use visual cues to identify tasks that may be slipping or off track. Hopefully you will find this feature helpful as well.





Posted by: Craig Harding | September 23, 2009

Tracking Administration Time in MS Project

Tracking Administration Time in MS Project

In my last blog I talked about making sure your resources are assigned the appropriate availability to work on tasks by accounting for administration time on projects. So how do you track this administration time in your project plan?

First of all you have to determine if you need or want to actually track the administration time in MS Project. If you are not using MS Project to track the budget of the project then you may have no need to track that time. In this case your budget is probably being tracked by some other time entry system that captures all time against the project.  Here, in MS Project you would simply track actual time against your hard project tasks that you have assigned to your resources. However, you want to make sure that your resources fully understand that they are not to charge and administration time to these hard tasks so you do not collect invalid times against your project plan.

If you are tracking your budget in MS Project and need to account for every hour spent on the project, then you need to set up a way to track the administration time. How you do this will depend on the level of detail you want to track here. As we said earlier, administration time is for soft deliverables on a project such as knowledge transfer, team meetings, status meetings, etc. You can set up tasks for each of these and assign a percentage of the resources time to each and track them individually. However, I find that this can sometimes just be added work for team members and for the PM to organize and make sure time is being gathered correctly. What I find works best is to have one ADMIN task running across the length of the project. Create the task as a “Fixed Duration” task and set resources’ UNITS at the desired allocation. You can then track the actual time against that task the same as any other task in the schedule.

If you have resources assigned to your project such that all of their time is to be charged against the project, even non-project administration time (company meeting, breaks, etc), you can also set up a separate task for that time if needed, or agree to track that time as part of your one administration task.

However you set up your administration tasks, it is important to communicate to your team how they are to account for their time against these tasks. Like all tasks in your schedule, it is also important to monitor the progress on a regular basis for irregularities and productivity issues.

If you have any questions or comments on this or any other topic, I am always looking for feedback.



Posted by: Craig Harding | September 16, 2009

Accounting for Administration Time in Project Schedules

Accounting for Administration Time in Project Schedules

 One of the most common mistakes I have seen in managing IT projects over the years is not adjusting resource availability to reflect reality. Many project managers simply set up their project plan and assign resources at full capacity. Even if a resource is only available on a project at 50%, I quite often see the resources assigned to hard project tasks at 50%. There are at least two areas that impact a resources productivity that are often not accounted for.

 Many studies have shown time and time again across all industries that no resource can dedicate 100% productive time to any project, even though they may be assigned 100% to that project. Two areas that impact this productive time are Project Administration and General Administration time.

 There are two types of task on a project; hard and soft tasks. Hard tasks would be those tasks that produce an actual deliverable. Good examples are a piece of code, a report, new screen, documentation, etc. Then there are soft tasks which describe tasks of administrative nature on a project that do not generate a specific deliverable. Such as project meetings, knowledge transfer, answering project related questions, status reporting, etc.  Research has shown that for most projects these soft tasks account for 20% of a resources time on a project. Therefore all resources that participate in these types of activities should only be assigned to hard deliverable tasks at 80% of their availability (6.4 hours of an 8 hour day if available 100%). If a resource is assigned to a project at 50% availability then 3.2 hours of an 8 hour day should be assigned to hard tasks. 

Far too often this 20% Project Administration time is not accounted for in the project plan and as a result hard tasks tend to slip as resources are not able to keep pace. The plan starts to fall apart and the team is left struggling to catch up from what was an unrealistic plan to begin with. 

There is another administration related time that can account for 5-10% time loss on a project as well. This is general work administration time that can take the form of bathroom breaks, personal phone calls, general staff meetings, etc. Depending on the environment you work in this time should also be accounted for. Some union environments also schedule regular breaks for employees, say ½ hour per day. This should also be reflected in your hard task schedule for each employee that is impacted. How you track and record this time differs from company to company and project to project. I will talk about tracking this time and recording the impacts on your project in my next blog.

As an example let’s take a project resource that works 8 hours a day, is allowed to take ½ hour per day in breaks, assigned to a significant number of soft tasks on the project, and needs to account for a work administration time. This resource should only be assigned to hard project tasks at 72% of their availability; that is 5.75 hours per day. (8 – .5 = 7.5 (actual working time) *.3 (Project & Work Admin Time) = 2.25) 

If you assume in your project schedule that this resource is working 8 hours every day against your hard tasks then your project is behind schedule before you start. Remember to account for reality and don’t omit Project and Work Administration time in your project schedules.



Posted by: Craig Harding | September 10, 2009

What makes a good project manager?

What makes a good Project Manager?


The success of a project rests upon the skillfulness of the Project Manager. New project managers, in particular, are prone to certain behaviors that diminish the likelihood of success. If you are aware of these pitfalls you can take action to get feedback and shift your behaviors.

The Inexperienced Project Manager

Unfortunately, many new project managers misunderstand their role—or bring to the role the behaviors and attitudes that worked for them in their old roles. Now those skills and behaviors are sub-optimal. Consider the three following approaches to managing projects and see if you recognize yourself:

The Senior Analyst as Project Manager – Promoted for outstanding performance in a technical role, the senior analyst has little experience leading people. He or she tends to value technical knowledge and wants to retain expertise. He or she likes to be involved in the system design details and favors familiar, technical activities over project management activities. Symptoms include:

  • He/she must personally inspect and approve design decisions
  • Scope is expanded to optimize technical solutions
  • Little attention to project plan maintenance and other controlling activities
  • He/she feels frustrated and overwhelmed and considers many of the PM activities administrative
  • Team doesn’t know scope or status of project

The Administration Manager as Project Manager – This is a common style for a department/functional manager. He or she will spend most of his/her time in meetings and will rely primarily on written reports and status meetings rather than first-hand observation. He/she is reluctant to publicize sensitive issues or problems and is willing to sacrifice short-term progress for long-term career development of subordinates. Symptoms include:

  • Maintenance of project plan delegated to a subordinate
  • He/she continues to focus on departmental activities
  • Problems sanitized when reporting project status
  • Project reported as on-schedule even when metrics point to slippage
  • He/she always in meetings—losing touch with what’s really going on.

Question: Can a project succeed when either the Senior Analyst or Administrative Manager approach is used? Yes, but if the project succeeds, it is usually the result of superhuman effort by the project team. And, if the project manager is credited for success, team members may be resentful and disillusioned. And, if the project fails—Management will tend to blame the project manager or the project team members, but the real reason for the failure may never be recognized or addressed.

    The Project Manager as true Project Manager

  • Sees project management as a professional role
  • Focuses on the project—not personnel administration or system design
  • Provides strong leadership and support to the team
  • Establishes procedures and monitors compliance with those procedures
  • Stays close to project activities, status, and issues
  • Does not shy away from delivering bad news.

 What are the effects of this true Project Management approach?

  • Status and issues are reviewed individually and frequently with each team member
  • Project plan reflects current status of all activities
  • Performance and capacity of each team member measured by objective data
  • Status reports focus on project metrics and identify open issues and changes
  • Team has sense of purpose and direction

The Project Manager must be a leader, organizer, scheduler, manager, planner, communicator, team builder, mediator, decision-maker, delegator, teacher, inspector, appraiser, persuader, and counselor.

How can you develop your ability to be a good project manager? Predisposition and attitude are important. You have to be motivated to develop your skills and to request and get feedback. You also have to take a disciplined approach. Project Management is somewhat of an art, but it is also a set of disciplines which, if learned and practiced, can make you successful.




Posted by: Craig Harding | September 1, 2009

What’s old is new again – Use Cases

What’s old is new again – Use Cases?

When I first started working on AGILE projects, I was unfamiliar with the term “use case”. I wasn’t sure if it was a new buzz word or a new technique for gathering requirements specific to AGILE style projects. As it turns out, I had been using them all along.

A use case is simply a way of describing a business task or action that takes part with in a system, process or application. Use cases should not be confused with the features of the system under consideration. A use case may be related to one or more features, and a feature may be related to one or more use cases. There are two kinds of use cases (Business and System), but for this posting I will only focus on the Business Use Case.

A Business Use Case is described in technology-free terminology, which treats the business process as a black box and describes the business process that is used by its business users (people or systems external to the business) to achieve their goals (e.g., manual payment processing, expense report approval, register a customer). The business use case will describe a process that provides value to the business user, and it describes what the process does.

About 15 years ago, I attended a training session presented by Trond Frantzen on Rapid Business Systems Analysis. In his methodology, he uses techniques for defining all of the “Events” of a business process or application in a very fast and concise manner. These events are essentially use cases. I have used this methodology successfully on many projects since that time and am now applying it when defining functional requirements (uses cases) in AGILE projects. Mr. Frantzen has now updated his publication to show how it can be applied within the AGILE framework. I would recommend reading his latest book Rapid ‘Agile’ Business Systems Analysis.

This methodology guides you through an event modeling process using JAD (Joint Application Development) sessions to develop ERD’s (Entity Relationship Diagrams), detailed Entity Data Dictionaries for logical database creation, as well as full narratives of the event as described by the business users. By populating entity relationship tables, you quickly identify all relationships in the process, as well as specific questions that need to be answered by the business. I have found that this process quickly provides the project team with a detailed functional business requirement in narrative and model form with all relationships between entities identified and specific data requirements documented. It is a quick and precise way of gathering detailed business requirements in use case or events form.

Whether you call them events, use cases, or detailed functional requirements, the end goal is the same. There are many effective and efficient ways of gathering this information. What are some of the methods or tactics you have used?



Posted by: Craig Harding | August 25, 2009

You think you have accounted for all the risks?

How do you plan for the unexpected in your project plan?

Those of us schooled in project management (PMIPRINCE2, etc) rely heavily on contingency and risk management planning. We meticulously go through the rigors of documenting risk, the probabilities of those risks and their potential impacts on the project. We also plan how we will attempt to stop these risks from happening, or at least be able to deal with them if they do happen. It is important that we include contingencies in our plans for both budget and schedule just incase something comes up that we haven’t fully understood or accounted for.

But what happens when things from out of this world wreck you project plan? Such a thing happened to me.

Several years ago I was managing a group of software engineers for an aerospace and defense company. We had to send a software guy to Mexico to apply routine updates to our software on several aerial surveillance aircraft. We had done this many times before and almost always took two weeks. However, being a good project manager I still allowed for a certain amount of budget and schedule contingencies in case of flight delays or customs issues.

After three days of applying the upgrades and conducting test flights, I get a call from our man in Mexico. All flights have been grounded. All software, hardware, and related recordings have been confiscated by the Mexican Government and the CIA. To top it all off, our software guy has been confined to the military base with no signs of release until further notice.

Apparently, on one of the test surveillance flights, the pilots encountered a series of UFOs that were recorded on both video and radar. You heard me right: UFOs. The incident has been documented here on YouTube. Needless to say we did not have UFOs recorded in the potential risk section of our Risk Management Log!!

Our employee was confined to the base for 6 weeks with limited outside contact, thus blowing my schedule and budget contingency out of the water. This also caused havoc with the other assignments I had scheduled for the recourse upon his return.

All of the risk management and contingency planning in the world would not have saved me on this one. In cases like this you just have to suck it up, chalk it up to one for the books and move on. That is, unless you have contacts in the interstellar world or Capt. Kirk on your project team to help your planning. And yes, our resource did make it back home without any further incidents. Though he did have a peculiar yellow glow about him…

What crazy things have caused some of your risk management plans to look inadequate?


Posted by: Craig Harding | August 19, 2009

Why not make AGILE agile?

So you have been asked to manage your first AGILE project. You have done some training and research but are still unclear about iteration duration or “time boxing” and “just-in-time” requirements. Should you go with two, three or four week iterations? Well, why not keep AGILE agile?

The whole premise of AGILE methodology is to be flexible and lean. “AGILE offers bare essential high-level requirements and the creation of detailed requirements just-in-time. This can be used for design and development within each iteration and can also be applied to the iteration duration or “Time Box” itself.” Some AGILE purists stay to the tried and true method of picking a constant duration for all iterations.

I have tried this and find that quite often you are trying to make a set of integrated functional requirements fit into a predetermined duration of development. Often, this is like trying to fit a square peg in a round hole; either there is not enough work to fit nicely in the allotted timeframe or there is not enough time.

So, why not make your “Time Box” flexible for each iteration such that it fits the work package that will be delivered? Your first iteration may be three weeks to allow you to deliver the functionality package, but your next iteration may require four weeks to complete a delivery. Give it a try.

You may be surprised how well the flexible AGILE methodology applies. Just be careful not to make your iterations too small. There is a significant amount of overhead in each iteration for deployment and code management. You also need to leave enough time for your business analysts and testing team to run the current iteration and prepare the detailed requirements and test plans for the next.

What experiences (good or bad) have you had with AGILE project Management?



« Newer Posts