Project management is always a matter of scale.  It is not a one size fits all proposition and there are times when we as project managers should remember to just do the simple things.  Sometimes the K.I.S.S. (keep it simple stupid) principle is really the best.  Imagine you have just been asked to organize the team rollout victory party for next week.  That’s the project.  You have 2 administrative assistants to help you.  That’s your team.  Are you going to develop a WBS dictionary, document a communication plan, and perform a quantitative assessment of risks?  I doubt it.  By the same token will you abandon any semblance of planning and completely wing it?  I hope not!  Not if you are a project management professional.  Any endeavor that is temporary and produces a unique product, service or result deserves a plan – one of appropriate size and scale.

Scope:  So, in our example you sit down with your 2 administrative assistants in your office and pull up a spreadsheet.  The 3 of you brainstorm what tasks need to be done in the next week to pull off the team party.  You discuss where the party will be held, what food will be brought in, how invitations will be handled, entertainment, etc.  You capture all these tasks in a column of the spreadsheet.  You have just defined the scope of your project as a list of tasks.

Resources: Next, you decide who is going to do each task on your list.  There are only the 3 of you on your team so one of the 3 of you has to be assigned to each task.  In a 2^nd column of the spreadsheet you assign a name to each task.  You have just performed resource allocation.

Schedule: Next, the team needs to determine when each task needs to be done.  This is an example of a time-boxed, fixed date project.  The party will be communicated for a specific date, so all preparation activities must take place prior to that date.  Working backwards from the party date, in a third column, the team fills in target date/times of when tasks must be completed by.  You have just performed activity dependency and scheduling for your project.

Budget: You think about how much each task will likely cost and note that in a 4^th column.  The sum of these cost estimates forms your budget.

Risk:  You ask your team “Is there anything that worries you?”   One of the admin assistants replies: “What if we can’t reserve a restaurant large enough on such short notice?”  So, you decide to add a task to the list to reserve a large conference room at your company and investigate catering at the company as a backup precaution.  You have just performed some risk management planning. Maybe it is not extensive or as rigorous as it could be, but it is better than doing nothing, and probably appropriate for this size effort.

Communication and project execution:  You decide to have a daily 15 minute meeting over the next week as you each carry out your assigned tasks.  I like the agile iterative process format for daily meetings as far as providing a simple way to get project updates.  In each meeting, every team member answers 3 questions:

1. What have you done since the last time we met?
2. What do you plan to do between now and the next time we meet?
3. What impediments are preventing you from making progress?

In answering those 3 questions, you are providing progress measurements that can be compared to the plan.  You are providing forecasts that indicate if adjustments are warranted.  You are highlighting issues and risks that may lead to offline discussions to develop ad hoc workaround plans.

With a simple spreadsheet and some basic, obvious conversation you can manage a small non-complex project.  The tools used are not important, as long as the necessary steps of the project management process are covered.

Processes:   The primary scrum processes allow for grooming of the product backlog or clarifying the complexity by specifying effort factor (story points), grouping work from the product backlog into work iterations, defining and estimating technical work tasks for the work iterations, and packaging completed outputs of the work iterations into a working release product.  Below is a breakdown of the different scrum processes along with their descriptions and analogous waterfall counterpart.

Meetings:    Since frequent feedback is the hallmark of agile, the scrum meeting are the settings that facilitate some of the above processes, as well as allow for frequent status during the work intervals or sprints, and provide the vehicle for the customer acceptance and process improvement.  Below is a table that describes the major scrum meetings, descriptions and their waterfall counterparts.

 Artifacts:  Artifacts are sparse compared to a typical waterfall methodology. All work “to do” is tracked on the product backlog.  Work “left to go”  is tracked on one of 2 types of burn down charts and are meant to show progress to the organization.  Business requirements will seem sketchy in agile as compared to waterfall since preference is given to conversations amongst members of the team, and verification through acceptance criteria and demonstrations.  Below is a description of scrum artifacts.

 In scrum, relative estimation keeps the estimation process intuitive and non specific.  It’s done in group session with the entire team where everyone “votes” on their number all at once to keep voting independent.  The relative story points assist the product manager in backlog prioritization.  Sprint planning makes up the rest of the planning for a 30 day period.  This is where the detailed task decomposition and hourly estimation occurs.

Once a sprint is planned, work is executed and monitored in the daily standup meetings.  Issues are tracked in the Sprint impediment log.  Progress is displayed to the organization in artifacts such as the sprint and product burn down charts.

At the end of the sprint, the work is verified and accepted or rejected in the sprint demonstration meeting.  Then the sprint processes are reviewed and suggestions for improvement are made in the sprint retrospective, before reprioritizing the product backlog if necessary and beginning a new sprint.

I first became interested in agile when I was leading technology teams and consistently struggled with the standard waterfall challenge of getting accurate, complete, well understand and well documented business requirements for long software development application projects.  Once we felt like we finally got things “nailed down” and began design and development work, requirements would change before we could deliver the first release.  The agile methodology is a natural solution for this.  I began my own course of self study, networking and training, and eventually acquired a scrum master certification.

To understand the principles of any of the flavors of agile methodology (and there are several), you need to first understand the agile manifesto, developed by the original set of agile founders:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Scrum happens to be one of the most popular types of agile and derives its name from a daily standup meeting called the scrum meeting, involving the team and the facilitator who is called the scrum master.  Below is a discussion which breaks down some of the important roles used in scrum and compares them to their analogous counterpart in a waterfall methodology. 

Roles – there are only 3 officially recognized roles on an agile scrum team:

• Product Owner – The product owner is a member of the scrum team and is responsible for what the team builds and for optimizing the value of it.  He/she owns decisions and risks regarding what business stakeholders want.  He/she defines the features to be produced and decides on release date and content, and determines feature priorities.  He/she can change features and priority between sprints.  He/she negotiates acceptance criteria for work results with rest of team
• Scrum Master – facilitates process and keeps things moving.  He/she manages the internal dynamics of the team including the relationship of the product owner with the rest of the team.  He/she enforces the scrum framework.  He/she ensures full team involvement in all meetings and keeps everything visible, including “radiating” information to the larger organization.  He/she shields the team from external interference.  He/she advocates improved practices.  Very important:  He/she facilitates, but does not manage.  The scrum master has no official authority over the team.  He/she cannot assign work to the team.
• Team – This is a small (7 +-2 member) cross functional group who are responsible for the work they agree to take on during the work period called a sprint.  They are a self organizing unit – meaning they assign sprint work tasks to themselves.  They negotiate the work of the sprint with the product owner.  Along with the product owner, they demo the work results to the stakeholders.

The product owner is analogous to a business analyst, product manager or sponsor in a waterfall methodology, and the team is similar to any team anywhere, with the exception of the self organizing part.  That’s a little loose-y goose-y for a lot of management teams to get used to.  Frankly, what I’ve seen in a lot of companies I’ve networked with is a gradual approach to this, because as much as this sounds like a great goal, in companies that have been highly command and control, teams have to get as used to it as the managers themselves do.  The scrum master could be similar to a technical team lead or a technical project manager in some organizations.  What is strikingly missing in this model is the overall project manager him/herself.  The traditional, all controlling, project manager doesn’t really have a direct correlation.  To find a home in an agile practicing organization the PMI style project manager has to make some decisions.  For individuals with a more product oriented, business slant, the product owner might be a great role to assume.  For the more technically minded, the scrum master role might be a better fit.

One of the most intriguing differences between agile and waterfall and what in my mind makes agile so compelling is in the area of scope control.  In the waterfall methodology we go to great lengths to define the scope of the project in as much detail as we can all up front, and then protect that scope.  We define a rigid scope change process which acts as a deterrent to anyone who wants to introduce changes to the work that we already have a complex tangle of design plans around, because of the cost and pain of implementation when you work on everything all at once.  With agile the notion of scope control is virtually non-existent, except within the context of the short periods of work, called sprints.  This is by design.  This is to allow and even encourage the product owner to be flexible and change their mind in between sprints as the business sees the results of work and reacts to it; and as events in the business change. 

In a nutshell, product features and all other work are maintained in a document called the product backlog, in single threaded priority by the product owner.  The team determines “chunks” of that work off the top that they can perform in time boxed periods of work called sprints (usually 30 days).  Once a sprint starts, the scrum master insures that the scope of the sprint does not change.  At the end of the sprint the team and the product owner jointly demo the work that has been completed to the business stakeholders.  The product backlog is reprioritized if necessary by the product owner and another sprint is started.  Sprints are repeated until enough work is completed to comprise a release.  Sounds simple huh?  Well there’s a little more to it than that.

In my next article I will discuss the small set of artifacts, meetings and processes involved and discuss what they compare to in a waterfall context.

According to Dictionary.com, a template is “anything that determines or serves as a pattern; a model”.  The idea of a Requirements Template is to provide your organization with a thorough and far-reaching list of questions or areas of inquiry to either answer or rule out at the beginning of every project.  If you include input from enough people and groups, whether they typically identified as project stakeholders or not, you can eliminate many of the scope problems that your organization’s projects might have encountered in the past. 

If you ever do projects for external customers, start your template-building exercise with Marketing and Business Development.  Ask them about what types of features customer and prospects initially express interest in and what marketing and advertising messages they respond to.  This can give you some good high-level areas of inquiry for your Template by helping you understand what prompts your external customers to engage with your organization. 

Next, visit with the Sales group and ask them to think about every problem customers have identified as wanting to solve when they accept a sales proposal.  Ask them also to think about customer satisfaction issues after a sale is completed:  what characterized projects that had satisfied customers, and what characterized projects that didn’t.  Ask them to describe situations where the customer was temporarily unhappy and why.  Ask to see any type of documentation they use to begin identifying what a customer wants. Then start building your list of questions. 

If you are dealing only with internal customers, start by reviewing the documents that accompany any request for a new project.  You want to include all of this information, but your template will go into much greater detail.  Interview someone from your organization’s Steering Committee and ask them what is missing from the current initiation documents they use.  Ask for examples of specific projects that got kicked back from the Steering Committee due to insufficient information, and get them to identify the types of additional information needed for them to make a ruling on a new project.  Continue building your Template by adding this to your list of questions.

Next, visit with all the teams that are responsible for executing the project plan.  Talk to developers, DBAs, cost estimators, trainers, folks who do the documentation; basically, everyone who actually performs work on a project in your organization.  Ask them for a list of everything they end up needing to know in the middle of the project that no one ever asked at the beginning.  Ask them what kind of work they are doing in the stabilization period, and if that work is a result of missed requirements.  Ask them for the most common examples, as well as the outliers.  Your goal is to create a comprehensive list of everything that should be considered at the beginning of a project.

Then move on to your support teams – whoever is responsible for the product of the project once it is operational.  Ask them to identify the things they wish someone on the project team was asking about.  Again, ask for the odd and unusual situations as well as the most common examples.

Finally, spend a little time with other groups that may not be at all involved in the project, but can potentially be affected problems with a project, like Legal, Accounting, Corporate Compliance and Public Relations.  Ask if they have ever been affected by missed project requirements, or have an area of potential concern around project requirements.  Document their concerns as areas of inquiry to consider during the requirements phase.

If you have all these conversations and hear all these war stories, you will be able to create a useful tool for the people in your organization who have the responsibility of collecting requirements.  Continue to updated and modify your Requirements Template as new information becomes available. 

In addition to getting your project off to a good start and nipping some scope creep issues in the bud, you may find that this tool helps you have better conversations with customers, both internal and external, by helping them uncover needs they didn’t know they had or gaps in their process they hadn’t discovered yet.

Good luck!

For the next few weeks, I will be blogging about how we, as project managers, can help our project teams think more creatively.  In my last blog, I looked at the systems and causes of teams that are in a creativity crisis.  Today, I offer the first technique for helping your team break out of a creativity rut.  I will follow with many more techniques over the next several weeks. 

The Six Thinking Hats was created by Dr. Edward de Bono, M.D., a pioneer in “deliberate thinking models” who believes that conventional thinking needs random interruptions so creative thinking can take place.  Dr. de Bono has several different approaches to thinking and has published many books over the last 40 years.  One of his most popular concepts is the Six Thinking Hats, which is designed to help groups think together more effectively.  Sounds like a great idea, right?  I have certainly participated in a number of “brainstorming” meetings over the years where precious little thinking was in evidence! 

The premise behind the Six Thinking Hats is that the human brain thinks in six discrete ways which can be harnessed individually to produce different ideas.  When considering the same topic, each of the six thinking states will generate different ideas on the same topic.  Each state is identified with a color, and many practitioners of this method will actually provide “thinking hats” in every color to every meeting participant.  By putting on a hat of a certain color, you are aware of the type of thinking you are engaged in. 

The six states and the associated colors are:

• Questions (White) – What are the facts?
• Emotions (Red) – What are the feelings?  
• Judgment (Black) – What are the flaws?  What are the difficulties and the dangers?
• Good points (Yellow) – What are the benefits? What is positive about this idea?
• Creativity (Green) – Where can we go with this thought?  What are the possibilities?  What are the alternatives? 
• Thinking (Blue) – Are we managing the thinking process?  

Obviously, the Black hat, judgment, is one that all project teams are familiar with.  With a cohesive team that works well together, you probably wear the Yellow hat and acknowledge benefits to the ideas generated by your group thinking exercises.  You may even put on the Green hat and get creative with teams that trust each other and enjoy collaborating.  A good project manager probably wears the Blue hat, for managing processes, quite often when running meetings. 

But what about the White hat, the facts? How often, when identifying requirements, solving a project problem or assessing a risk, do we rush through the facts?  Or treat assumptions as facts?  Or treat facts as assumptions?  Wearing the white hat, either literally or figuratively, might help our teams avoid some project problems. 

And finally, the Red hat, which represents emotions.  Few project teams spend any time or effort on emotions, unless the ignored emotions erupt, causing a situation that has to be confronted.  Not only is it useful to address your project team’s emotions, you have to put the Red hat on and discuss emotions when you are planning any sort of activity or event that will change people’s jobs.  Any student of Organization Change Management will tell you that you ignore organizational emotions at your peril.    

De Bono’s Six Thinking Hats can help you think comprehensively about any topic confronting your team.  This has been a very brief overview, but there is plenty of information available online to learn more about this technique.  For more information, start at Dr. De Bono’s website, http://www.debonogroup.com/six_thinking_hats.php.

Stay tuned next time, for some additional techniques to improve team creativity.

The project schedule is a key artifact of any project.  It’s first function during planning is to determine the baseline milestone dates for the project, but it should be an active document that lives on throughout the project.  It should always reflect the latest target milestone dates as well as updated progress towards those milestones.  As such it serves as one of the primary communication tools on the project.  Therefore it should be structured in such a way that it is convenient for update by those that must maintain it, and at the same time should communicate information in a form that is relevant to the stakeholders that consume it.  The amount of detail revealed should vary by audience.

This starts with giving thought to the layout of tasks on the schedule.  I advise structuring multiple levels of organization. 

1. Make the first or outer level of organization align to whatever is important to the business sponsors you will be answering to.  This will obviously vary from project to project and assume you have done a good job determining this in scope definition.  This might be something such as implementation of a new CRM application, or construction of a new facility.  That way you can always collapse the sub-levels of detail below that and get an overall status that is of interest to the business. 
2. The second inner level of organization can be by team (such as software development, or desktop support,  or electricians, or landscaping). 
3. The third level of organization can be by phase or life cycle or activity within the team (such as software requirements, testing, desktop computer upgrades, foundation, framing, etc.). 

Where possible, use summary or rollup tasks so that underlying detail can be hidden when appropriate.  Sometimes an entire section of work activity is led by a sub-team leader and a separate project schedule is maintained by that person.  When this is the case, I recommend reaching agreement ahead of time on summary tasks in the master schedule as alignment points with the “sub-schedule”.  Then the sub-team leader can maintain the detail in his/her schedule and simply report on the status against the summary task.

Finally, the project schedule is a wonderful tool for communicating if used properly in meetings, but as mentioned in a previous article, it’s never a good idea to display it in order to gather status and do updating in the meeting.  That’s the project manager’s job to be done before the team meeting in individual one on one settings with team members.  Once updated to reflect the latest status toward milestones, the project schedule should then be viewed (with appropriate detail shown according to the audience) to communicate current progress.  One of my favorite tools I add is a stoplight field which is automatically updated each time the schedule is opened, that sets itself to red, yellow or green (or blank) indicating whether the task is not due to start yet, on target, at risk, or overdue.  This helps immediately draw the eye to those tasks that need discussion and prevents wasting time on tasks that either haven’t started yet or don’t require intervention.

Remember, project management is more than anything else about communication, and the project schedule should be one of the key tools to aid in that communication throughout the project, so keep it current and keep it relevant to each audience where it will be viewed.