The SDLC is *NOT* a Project Management Methodology

render of a five step software development process

We need to institutionalize the SDLC as our organizational project management methodology” – The Ill-Informed, Buzzword-Loving Senior Executive

A common misperception amongst project stakeholders is the erroneous belief that the Software Development Life Cycle (SDLC) is a project management methodology.  There are even some who believe the inverse, that the SDLC is contained within traditional project management methodologies.  In truth, neither are quite correct, and it’s more than just semantics.  Here’s why…

The Software/Systems Development Life Cycle is a methodology that forms the framework for planning and controlling the creation, testing, and delivery of an information system.  More specifically, the SDLC process is composed of a number of clearly defined and distinct work phases which are used by information technology resources, such as systems engineers and systems developers to plan for, design, build, test, and deliver information systemsThe SDLC is about quality, consistency and product delivery in the realization of a product’s requirements.  In recent years, SDLC methodology has been modified to become more streamlined and less “waterfall” based, with the popular Agile approach being one example.  In most circumstances, the SDLC process is managed by a AppDev Manager, Business Analyst, Systems Analyst, SDLC Team or other systems development professionals.

Project Management Methodology on the other hand, is the application of knowledge, skills, tools and techniques to meet project requirements through planning, organizing, measuring, controlling and reporting upon resources (human, financial and time).  Best practices within traditional project management discipline list five main phases or “process groups” that include Initiating, Planning, Executing, Monitoring & Controlling, and Closing. The management of a project includes identification of requirements, balancing stakeholder needs/expectations/concerns and balancing competing constraints (scope, quality, schedule, budget, resources, and risk).  Within each phase, tasks are defined to move from one phase to another until the project is closed.  More recently, modifications to the traditional five-phase process have been developed to more appropriately address specific project management needs such as Prince2, Critical Chain, Lean and Benefit Realization.  Again, in most circumstances, the PM methodology is managed by a Project Manager or other project management professional.

In reading the last two paragraphs, you can immediately see the cause for stakeholder confusion can’t you?  Both methodologies use the same language:

  • Planning
  • Controlling
  • Phases of Work
  • Tasks
  • Requirements

Despite the similar language, care should always be taken to distinguish between the project life cycle and the product life cycle.  The important distinction being that the SDLC is completely focused on the phases, tasks, resources and plans needed to deliver information systems.  Project management methodology is more agnostic.  It’s process set and approach can be applied to any temporary endeavor with a defined beginning and end, whether it’s a construction project, a school research project, planning a move from one city to another or even an IT infrastructure upgrade project.

Now that the differences have been established, let’s spend some time on how and why the two can, and should, co-exist on any information system delivery project.

PMLC-SDLC

The project kicks off in the Project Management Initiation Phase.  The initiating processes determine the nature and scope of the project and produce the Project Charter, which serves as the project’s guidepost of what is expected to be delivered, in what timeframe, under what constraints (schedule, budget or quality) and leveraging which key resources. The Initiation Phase is also commonly where projects are reviewed and approved by a larger project portfolio or governance board.

With some kind of approval to proceed secured, the project enters the Planning Phase in the PM methodology.  Early in this phase, the project is planned to an appropriate level of detail, with the main purpose being the identification of project deliverables, establishment of key milestones and the assignment of resources to the effort.  Running in parallel on the SDLC process track, work activities focus on analyzing user needs and developing business and system requirements.

While the PM process progresses into breaking down the deliverables into tasks, sequencing those tasks and estimating resource effort vs. capacity, the SDLC track is busy with the System Design phase where the requirements that have been gathered are used to outline the desired features and system operations in detail, including screen layouts, business rules, process diagrams, code templates and other documentation.

Once the project plan is in place, the schedule set and the budget established, the project enters the Execution & Control Phase on the PM Life Cycle.  Here, actual coding and development tasks are started and test plans are documented.  Blocks of code are gradually completed and unit tested, leading to system functionality being delivered.  Issues are tracked and worked, while risk begins to decrease as more key milestones are met.

As the bulk of the coding and development tasks begin to wind down, testing activity starts in the SDLC Test Phase.  There is commonly an iterative relationship between Development and Testing as coding defects are discovered and sent back to development for fixes, which are then tested again until approved.  The project phases of Execution and Control also become iterative, continuously looping between tracking the execution plan and making adjustments based on the actual results via control mechanisms like earned value management, task completion, budget and schedule tracking and stakeholder management.  At the conclusion of these parallel tracks in both the SDLC and Project Management methodologies is the implementation/deployment of the final, tested solution.

Finally, the project management process wraps up the project by confirming that the delivered solution meets the scope parameters and requirements identified at the beginning of the effort.  Lessons learned are captured, documents are closed out and filed, resource recognition and celebrations are held, the system is handed off to the operations team and the project is officially closed.   But the SDLC process takes one more step (not shown above), starting with that hand-off to the operations team.  Known as the Maintenance Phase, the implemented solution is managed in a day-to-day operational state, where changes, enhancements, fixes and end-of-life planning considerations are made.

So remember, the SDLC is *NOT* a Project Management Methodology.  The two should never compete against each other during the life of a project initiative.  In fact, the two are completely complimentary to each other for information systems development projects.  In a perfect world, the PM processes should be led by a Project Manager and the SDLC processes should be overseen by a Systems Manager.  In an imperfect world, the Project Manager should at least solicit the help of a systems developer to ensure the SDLC best practices are defined and tracked on the systems development side of the effort.

Help The New PM – Create a PM Process/Artifact Checklist

checklist

Starting your first day at a new job, especially as a Project Manager, can bring feelings of helplessness and confusion.  You don’t know the people, the politics, the processes or even the tools available to you.  Sure, project management methodology is relatively standardized today, but organizations still have their unique quirks, process steps and bureaucratic requirements.  Honestly, it takes some time to learn the ropes, meet the key players and understand the hidden agendas.  There’s no denying that fact.

But there is one tool that can help shorten the learning curve…a checklist.  Those of you familiar with the ground-breaking work of Atul Gawande, “The Checklist Manifesto,” know that a checklist helps professionals deal with the increasing complexity of their responsibilities.  For those not familiar, Mr. Gawande is a surgeon who became frustrated with the poor outcomes of patients resulting from simple, avoidable mistakes.  He discovered example after example from his medical peers showing how the routine tasks of surgeons have become so incredibly complicated that mistakes of one kind or another are virtually inevitable without following some type of checklist.  His research into this area exposed him to the use of checklists and other similar process review tools used by airline pilots, risk managers, financial planners and….PROJECT MANAGERS!

The creation of a project management process and document artifact checklist isn’t really that complicated.  Many of you come from organizations with well defined project management processes and methodologies.  Leverage those process maps, methodologies and swimlane diagrams!  I’ve provided a snapshot of the Initiation & Planning Phase checklist that I have developed in previous roles.  I have similar checklists for the other three phases of the traditional project management life cycle and even have different variations of these checklists based on project type.  These checklists have proven invaluable when on-boarding new employees or contract PMs.

Slide1

Note that, beyond the actual project methodology steps, I also added the required meetings, approvals/sign-offs and documentation needed during the phase.  The blank lines are for “special” checkpoints that may be required by a certain stakeholder or a certain project type.  Believe me, when you get to the final gate review meetings, you want to make certain you’ve completed all of the requirements needed to gain approval.

Every checklist is unique.  Ideally, you want your checklist to incorporate all of the important things that you need to validate before proceeding to the next step.  You also want your checklist to be simple, free of jargon and easy to follow by just about anyone on the project team.  This brings up an interesting point about checklists, if all you need is a checklist to manage a project, why do I need a high-priced Project Manager?

Believe me, if it were really that simple, every organization would be dropping PMs like third-period French class!  Project Manager’s bring a wealth of knowledge about how to break down large work efforts into logically sequenced tasks, managing teams comprised of widely-varied subject matter experts and communicating information across the broad spectrum of project stakeholders, from technical minutia all the way up to the concise, financially focused detail required at the leadership levels.  Project Managers are adept at both the science and art of managing complex work efforts.  Checklists help ensure that the science is addressed, while keeping focus on the art.  As an added benefit, checklists allow new Project Managers and other team members to become productive much more quickly.

Leaders Make Time For Ideas

ideas1

Successful leaders focus on the future.  Setting a strategic direction comes from looking into the future, envisioning a better place and then developing the plan to get there.  In most cases, that vision of the future will require new ideas and fresh ways of thinking in order to reach the desired new outcomes.  But new ideas are hard to come by…becoming especially elusive as more focus is applied to the task.

Purposefully searching for new ideas takes practice and self-discipline.  Leaders must challenge themselves, and their teams, to learn about, and take advantage of, the problem solving process.  We’ve all experienced that game-changing idea that smacked us in the side of the head when we least expected it.  So, how does that happen?

Let’s start with a question: Where do you find yourself, and more importantly what are you doing, when you get a great idea?

I’ll bet that you said something close to one of the following:

  • Cutting the grass
  • Walking the dog
  • Driving to work
  • Taking a shower
  • Listening to music
  • Meditation/Praying
  • Bird watching

I’ll also be willing to bet that not one of you said, or even thought of, “sitting at work.”  Not surprising.  So why is it that you always seem to get your best ideas when you are doing the activities mentioned above?  Strangely, it is the lack of direct focus that is the key.  It is during these mundane activities that you get as close as you can get (at least during waking hours) to your subconscious, the idea generator in your mind.

Subconscious, you ask?  Absolutely!  The subconscious is the “back office” of your mind that takes care of recording everything you encounter via your five senses and uses that information to continuously solve problems.  In fact, it can solve problems faster and better than any computer yet invented by Man.  By using the examples of the recordings it has made throughout your life, and comparing them to the problems you have assigned it (whether consciously or unconsciously), your subconscious develops potential solutions to your problems…or in other words…it provides you with an idea!

Unfortunately, we lead incredibly complicated and busy lives.  So busy, in fact, that we often cannot hear our subconscious when it’s trying to tell us that it has found an answer to one of our problems.  When you engage in one of the activities mentioned above, your conscious mind goes on “auto-pilot” and you start day-dreaming or “zoning out.”  In reality, you are tapping into your subconscious and interacting with it.  Sometimes it has answers (ideas) for your problems…sometimes it doesn’t.  But now that you know how it works, you can use the world’s most powerful problem solving tool to your advantage!

Then next time you have a problem or challenge, assign it directly to your subconscious.  You’re probably asking, “How the heck do I do that?”  It’s simple.  State your problem out loud, or better yet, write it down on a piece of paper.  Now, do it again.  And, one more time for good measure.  Next, take that piece of paper and shove it in a drawer.  Okay, completely forget about that problem.  I mean completely.  Don’t worry, it’s written down.  If you start to think about it, just tell yourself that you already assigned it to the subconscious and the problem is in the process of being solved.  Give yourself at least a few days to let the subconscious sort through the “stuff” in your head.  Now, find the one activity that most effectively eliminates the noise in your head.  It could be driving or showering or whatever.  Think about, or haul out that piece of paper and read, the problem out loud.  I think you’re going to be surprised at what comes out.  Be ready to write down the ideas as they come to you.  Great ideas are fleeting and are gone as quick as they come!  If your subconscious hasn’t found a solution yet, don’t despair!  Just keep finding those quiet moments in your day and you won’t be disappointed.

Pretty simple tool isn’t it?  And we all have it available to us 24×7.  But, like anything, it works best when practiced.  It also needs care and feeding.  Your subconscious is really only limited by the “recordings” that it has made via your five senses.  So, if you find yourself with a slow down in ideas, try to “feed” it something new like:

  • Read a book or magazine (especially outside of your expertise)
  • Watch the Science or History Channel or anything different from your normal routine
  • Visit your local museum or library
  • Talk to a friend you haven’t heard from in a long time
  • Go out, find some of your customers, and talk to them
  • Take a walk in the woods, or at the beach, or even on the busiest street in your town
  • Travel to a new place
  • Take a random day off in the middle of the week
  • Visit a new restaurant

You get the idea.  You need to expose yourself to new experiences in order to expand your problem solving capabilities.  For your inner idea generation machine to work effectively and efficiently, you need to follow this system:

  1. Feed your mind fresh, new observations
  2. Write down your problem or challenge, then forget about it for a while
  3. Find times during the day to quiet your mind and listen to yourself
    1. Note which activities tend to lead to more ideas and seek out those times more often!
  4. Listen to the ideas that pour out of your subconscious and write them down!
  5. Repeat!

Leaders make time for ideas, show the way to getting more ideas and encourage others to seek out their own ideas.  Ideas solve business problems.  Business solutions lead to a better future.  And a better future is strategy well executed.

 

 

 

Effective Project Meeting Formats

effective_meeting_2

Project Managers (and project team members) spend way too much time in meetings.  And, let’s be honest here, the reason for that is most likely the fault of the Project Manager him/herself.  This wouldn’t necessarily be a bad thing, if the meetings were productive and meaningful.  Some are…most aren’t.  One of the most useless project-related meetings is the Status Update Meeting.

Status updates on the project should be reserved for written communication channels.  Using a Communications Plan can spell out exactly what types of the project-related communications (including status reports) are distributed, how, when and to whom.  Project Managers are the experts on preparing and distributing status reports.  Want to know the status of the project, read the report.  Too lazy to read, call the PM.  Too lazy to call, looks like you don’t need to know the status.  I knew a PM who actually used the status meeting to find out what happened on the project since the last meeting.  Really?  That’s amazing project leadership and engagement! (sarcasm off)

The ONLY time you should review the status of a project in the setting of a formal meeting is to introduce the project and its current state to non-stakeholders.  Meetings like Quarterly Executive Briefings, Divisional Staff Meetings, etc.  In any case, the status portion of the presentation should be very brief.

So what kind of project meetings ARE valuable and effective?

  1. The Project Planning Meeting(s) (PM & Project Resources):
    • Project Team kick-off/introductions
    • Discussing scope limitations and agreeing upon the collective “Definition of Done”
    • Work/Task breakdown activities
    • Task sequence mapping
    • Estimation of task-based work effort, task durations, scheduling lags, CapEx, OpEx, etc.
    • Creation of the Project Team Calendar (Vacations, On-Call, etc.)
  2. The Daily/Weekly Project Team Working Meeting (PM & Project Resources):
    • The Project Briefing Format:
      • Tasks completed last week
      • Tasks lagging
      • Tasks in progress
      • Tasks starting this week
      • Risk/Issue discussions
      • Decisions needed
      • Distribution of project statistics
    • The Agile/SCRUM Meeting Format:
      • What did you complete this week?
      • What are you planning to complete next week?
      • What is in your way that needs escalation?
  3. The Monthly Project Leadership Team Meeting (PM, Project Sponsor, Key Project Stakeholders or Steering Committee):
    • Review project statistics/dashboard
    • Discuss risks/issues that have been escalated
    • Decisions required that have been escalated
    • Discuss resource concerns
    • Verify strategic alignment
  4. The Weekly PMO Working Session:
    • Rules: NO status reports will be allowed!
    • Invitation Only:
      • PMO Leadership
      • Project Manager
      • Project Leadership Team (Sponsor, Lead(s), etc.)
    • Rotating Schedule:
      • Week 1:
        • Project Funding Request/Gate Approval Discussions
        • Recommendations/Decisions published after meeting
      • Week 2:
        • Issue/Risk Mitigation and Change Request Discussions
        • Recommendations/Decision published after meeting
      • Week 3:
        • Project Budget/Schedule Audit Reviews
          • Projects will be selected at random and given 1 week notice
      • Week 4:
        • Project Initiation Presentations
  5. The Quarterly/Monthly PMO/Portfolio Review Meeting (PM, Executive Sponsor, Project Sponsor, EPO/PMO Director):
    • Present project status in dashboard format across the following key performance indicators:
      • Budget
      • Resources
      • Risks/Issues/Changes
      • Timeline/Roadmap
      • Integrations with other Lines of Business
      • Benefit realization
  6. The Informal 30 Second Briefing or “Elevator Speech”
    • Be able to summarize the current state, key obstacles and coming deliverables in 30 seconds or less

Project Managers spend enough time generating project status reports, risk registers, issue logs, dashboards and other written forms of project information.  Having to rehash this information in a meeting setting just wastes everyone’s time.  Project meetings should be focused on tasks (starting, continuing or finishing), issues, risks, resource availability concerns, changes proposed and decisions needed.  Documents should reflect history, while meetings should invite action.

The PMBOK Is A Menu…Not An End-to-End Process

menuIcon

I’ll never forget the training class I took to begin my preparations to pass the PMP exam (can it be eleven years already?!)  The instructor was a burly man, whose experience with project management included the NASA space program, two high-rise construction projects in downtown Chicago, and a massive, cross-country data center move for a Fortune 10 organization, among other “trivial” project work.  He walked to the front, empty table in the hotel conference room and dropped a copy of the 3rd Edition of “A Guide to the Project Management Body of Knowledge,” better known as the PMBOK Guide, down on the table.  After a long pause, he said the following in a loud, booming voice that needed no amplification, “This…is a copy of the PMBOK Guide, which, collectively, contains everything you need to know to successfully manage a project and pass the PMP exam.  If you take the initiative to follow it from end-to-end, your project will be a complete and utter…….FAILURE!”

You can imagine the thoughts running through our heads.  Most of us had managed projects before.  Most had heard of the PMBOK, and some had even consulted it for best practices prior to the training.  I know that my assumption of the PMBOK at the time was that it was THE guide, from beginning to end, for managing projects.  Little did I know that I was both right, and wrong!

As we spent the next few days walking through the project management framework, life cycle, process groups and knowledge areas, it became clear that the PMBOK was really a massive “menu” of tools, techniques, processes and exercises to leverage during the course of the project.  There is a life cycle, yes, and a logical flow from initiation to closing.  But within each project phase, process group and knowledge area there are upwards of thirty different tools, techniques, exercises, meetings, document artifacts and other suggested activities or deliverables.  Multiply that times five phase/process groups and nine knowledge areas and you can see the sheer magnitude of available systems.  Quite honestly, you couldn’t possibly implement each and every artifact contained within the Guide and still manage to deliver the project on time or budget.  Purists will scoff…but they know I’m right.

Does every project need a Histogram?  Or a Stakeholder Power/Interest Grid?  What about a Quantitative Probability Distribution chart?  Every project needs a Requirements Traceability Matrix right?  You consciously decide among Analogous or Parametric estimating on every project, don’t you?  Really?  Be honest, you’ve never even heard of at least one of those artifacts or tools have you?

The Project Management Life Cycle is a tried and true, end-to-end process that, more often than not, results in a successful project outcome.  The PMBOK expounds upon that life cycle by providing proven, best practice tools, processes, techniques and other systems to either effectively and efficiently move the project forward or deal with special issues that arise during the initiative.  In essence, the PMBOK is a massive menu.  It contains thousands, maybe millions, of unique combinations to lead, manage and deliver a project-based work effort.

Some organizations dictate that a certain number of artifacts be required to assure proper project management protocol is followed.  For example, each project must produce at least a Charter, a requirements document, a budget worksheet, a task list, etc.  Beyond those minimum requirements, the Project Manager is free to choose the tools and techniques contained either in the PMBOK, or based on professional experience, needed to manage that specific project.  Some projects will need a formal issues log, some can be handled less formally.  Some projects will need a full work breakdown structure to identify and organize the work, while others can be set up with a simple task list.  By definition, each project is unique.  The method to manage each project should be just as unique.

There are also some organizations that require junior Project Managers to follow more prescriptive processes and leverage a longer list of tools/techniques both to boost the odds for success and to expose the resources available to them.  More senior Project Managers are given further latitude regarding what is, or is not, required for each work effort.  The best Project Managers have developed their own list of artifacts and systems that are “required” by them, and then add to that list as each situation arises.

The key point to remember is that the PMBOK is a menu, and *NOT* and end-to-end process map.  Lean on it to provide you with guidance and options.  Keep what you need or works and toss the rest.  Each project is a “Build-Your-Own” management effort.  Your project management rigor should resemble a modern freeway.  The centerline is the ideal path.  The ditches and guide rails are the limits of how far you can stray.  Apply just enough discipline, including the resources available in the PMBOK, to keep the car on the road!

Answering Project Stakeholder Questions

dreamstimemedium_19473030-300x300

As a project manager, one of the most important skills you need to master is effective communication.  Being able to communicate with a wide range of people, using their own sub-language (IT-ese, Finance-ese, Engineer-ese, etc), is critical during the entire course of a project initiative.  Perhaps one of the most important groups you will interact with frequently as you traverse the various project phases are the key stakeholders, without whom you wouldn’t have the funding or resources necessary to execute on your effort.  Stakeholders will have many questions during the lifecycle of the project and it is your primary responsibility to be in a position to answer those questions.

During my almost two decades of managing project, programs and portfolios, I’ve amassed a set of critical questions that come up (or should be asked) during the course of almost every project.  To help you think about and prepare honest, accurate and coherent responses as they related to your project, I’m giving you some advanced warning on what to expect.

If you can answer all of these questions during the project effort, you’ll have demonstrated that you are an effective, efficient and trust-worthy project manager:

Stakeholder Questions At Project Planning Launch:

  1. What do we want to accomplish?
  2. What…specifically…are we delivering at the end of this effort?  (What does “Done” look like?…thx Glen Alleman! @galleman)
  3. Who will take responsibility for what we are delivering once this effort is over?
  4. What are the key deliverables that we need to accomplish to reach our end goal?
  5. Who do we need to help us define and sequence the tasks needed to meet those key deliverables?
  6. Who do we need to complete the tasks needed to meet those key deliverables?
  7. How much time do we need to meet those key deliverables?
  8. How much money do we need to meet those key deliverables?
  9. What are the risks we can anticipate that might keep us from meeting those key deliverables?
  10. How will we react to the aforementioned risks if they occur?

Stakeholder Questions At Project Execution Launch:

  1. What are we tracking to know we are on schedule?
  2. What are we tracking to know we are on budget?
  3. What are we tracking to know we are making progress on completing our key deliverables?
  4. How will we identify risks and/or issues?
  5. What will be our responses to the previously identified risks and/or issues?
  6. Who else needs to know the answers to these questions and what is their preferred communication channel?
  7. Do we have the appropriate amount of resources (human, budget, space, etc) necessary to execute the estimated work effort?
  8. Do we have the appropriate amount of leadership commitment and oversight to ensure a quality project delivery?
  9. Does our effort have any dependencies or conflicts with any other efforts currently being conducted within the organization?
  10. Have we identified any other “part-time” or transient resources required for project delivery?

Stakeholder Questions At Regularly Scheduled Project Status Meetings:

  1. Are we on schedule?
  2. Are we on budget?
  3. Are we making progress on completing our key deliverables?
  4. Are we confident the key deliverables meet our quality standards?
  5. Are there any risks and/or issues that have come up since the last time we met?
  6. What is our response to the risks and/or issues?
  7. Do we still have enough time, money and resources to complete our key deliverables?
  8. Are there any changes required to ensure we have enough time, money and resources to complete our key deliverables?
  9. Is there any opportunity to speed up the schedule, reduce cost, free-up resources or deliver additional tasks without negative impact?
  10. Are the right people being informed of our progress and status?

Stakeholder Questions at Project Closure:

  1. Did we accomplish what we promised at the beginning of the project, plus or minus any changes handled via the approved change management process?
  2. Did we successfully complete the key deliverables promised at the beginning of the project?
  3. Did the person tasked with the responsibility for receiving of work product agree to accept the deliverables without the need for additional effort, time, money or other resources?
  4. Did we deliver our effort on time (within acceptable variance)?
  5. Did we deliver our effort on budget (within acceptable variance)?
  6. Were the deliverables of acceptable quality?
  7. Were there any significant risks and/or issues that caused us stray outside the acceptable variance limits set for the effort?
  8. Were the right people communicated with regarding the completion of the effort and the results?
  9. Have the resources (human, remaining budget, space, etc.) been released for other use?
  10. What are the lessons learned from this effort that may benefit future project teams?

Be proactive.  If these questions don’t come up, ask them yourself.  Remember, stakeholders come in all different levels of project management maturity.  Those new to the concept will appreciate your guidance and coaching on what is important to ask and consider when moving through the methodology.  This is in no way a complete list.  Each individual project will have unique questions that arise and need to be understood and addressed.  But what’s listed above represents a solid foundation of project management specific questions that, when answered, will give the key stakeholders of your project confidence that the person managing their effort (ahem…you!) is skilled, competent and fully capable of managing the work.

 

What Ever Happened to the Concept of Contingency Planning?

Plan-B-image-640x340

I love attending status meetings where a Project Manager has to explain why his or her project went from Green to Red.  Yes, you read that correctly…Green to RED!  Whoa!  Something really serious must have happened to go from “everything is right on the line” to “full stop!”  Discussion usually ensues about how everything on the project was going along swimmingly until suddenly, a piece of technical hardware that was supposed to ship last Tuesday won’t ship until a month from Tuesday.  And, since every task on the project schedule is on the critical path, there’s no way to recover from this event so the project is going to be delivered late unless drastic measures, like cutting scope or pushing out the date, are immediately executed.

This is where I shake my head and wonder…what ever happened the concept of project contingency planning?  Why are projects being scheduled so tightly?  Why do project budgets have no reserve funding for unexpected events?  Don’t they teach this stuff anymore?

So what is project contingency planning?  A contingency plan is a risk management tool devised to account for an outcome that is other than the usual or expected plan.  In project management, typical contingency planning efforts revolve around a couple of concepts, Schedule Slack (or Float) and Financial Reserve Funds.

Schedule Slack is the amount of time that a task can slip before it affects another task or the project’s finish date.  There are actually two different types of slack:

  • Free slack, or how much a task can slip before it delays another task; and
  • Total slack, or how much a task can slip before it delays the entire project

Many projects have natural slack within their schedule based on the way the tasks and sequencing fall according to the work breakdown, resource availability, product delivery lags, etc.  In order to find that slack, you’ll need to know how to develop a task network diagram, identify the critical path of your project and identify non-critical task chains.  The Project Management Body of Knowledge (PMBOK) or many online resources can help you map that diagram if you are unfamiliar with the concept.

Smart project managers, however, build a small amount of artificial slack into their schedules.  Nothing ridiculous obviously, but spacing some tasks out a few days here and a week there allows the PM with some maneuverability and options if and when issues or risks pop up that will affect the overall schedule.  Be very careful with this approach so that resources are not unnecessarily sitting idle just to build in a bit of float for your schedule.  Depending on the size of the project, I’ll typically build in at least one segment of float within each phase of the project and then collapse the schedule if I don’t actually need the time.  Being up front and openly communicating this approach with stakeholders and team members is a must!

Financial Reserves are funds set aside for a “rainy day” that may occur on the project.  These also come in a couple of different types:

  • Contingency Reserve, which is an amount of money set aside in the event that identified and quantifiable risks are encountered during the course of the project.  The Project Manager will typically have the authority over this reserve and will include it within the overall project budgetary accounts.
  • Management Reserve, or money that is set aside by the project sponsors or leadership team as an insurance policy against the “unknowns” that may arise during the project.  The Project Manager does not have authority over these funds and, if needed, must request them from the project leadership team.  These funds are may or may not be included within the overall project budget.

Let’s be honest, there are many project managers and stakeholder teams that “round up” the amount of CapEx (Capital Expenses) and OpEx (Operational Expenses) needed for a project.  Building in a just a bit of extra budget, up to five percent or so, is a sensible, and sometimes responsible, action depending on the uncertainty of the overall costs.  The financial reserve funds referenced above, however, are NOT project budget “padding.”  They are designed to cover known risks or unknown environmental factors.  Some project leadership teams expect a certain amount of scope change during the project and use the Management Reserve to fund these changes.  Best practice dictates that accessing any of these reserved funds must follow strict change management protocol.

Effective use of contingency planning in project management allows the Project Manager with more palatable options beyond the reactionary approaches of crashing the schedule (adding more resources to tasks so they finish sooner) or fast-tracking (running tasks previously scheduled in sequence to be run in parallel).  Some projects may never need the extra calendar time or the additional funds needed to get across the finish line.  Honestly, I’d much rather facilitate a project closing meeting with the Project Sponsor where I was giving back money set aside for a rainy day and/or ending the project a bit early by collapsing the available slack, than going, hat-in-hand, begging for more money or time based on having the project go from Green to Red!

Ten Things Walt Disney Taught Me About Project Management

project_management3

Often times, the study of project management concept and practice concentrates primarily on the academic, filled with complex charts, graphs, formulas, and page after page of bibliographic reference.  What if, instead, the focus was on the most simplistic definition of a project?  Better yet, what if that definition was one a dreamer like Walt Disney could wrap his creative mind around?  At its heart, a project is a new or unique undertaking, which meets a business need, is temporary in nature, and is structured in such a way as to ensure delivery of the goal within the targeted time, budget and quality constraints.  Put even more simply by Walt Disney himself, “If we can dream it, we can do it.”

____________________

“When we consider a project, we really study it…not just the surface idea, but everything about it.  And when we go into that new project, we believe in it all the way.  We have confidence in our ability to do it right…and we work hard to do the best possible job.” – Walt Disney

Lesson One: Pay fantastic attention to detail. 

Any project, as defined above, can not and should not be managed as a whole.  It is the sum of many small details across many distinct process groups.  Keeping track of these details makes the difference between a well managed project and a project managed by reactionary efforts.  Tracking the details, anticipating issues, responding to risk, and keeping watch over a myriad of other seemingly non-connective tasks are what keeps your project moving forward.  Don’t get too bogged down in the weeds with your team however, as your main role is to keep one eye on the end goal and keep the project moving in that direction.  Always know where your project is today, where its going tomorrow and what challenges your team is facing so you can effortlessly communicate these facts to key stakeholders.

 ____________________

“I happen to be an inquisitive guy and when I see things I don’t like, I start thinking, ‘Why do they have to be like this and how can I improve them?’” – Walt Disney

Lesson Two: Challenge the status quo.

How a project manager responds to issues and risk can make the difference between an “out of control” project and a project “within control limits.”  One of the major steps of the project management maturity model is recognizing and avoiding past mistakes.  When we ignore our project success/failure history, we are sadly doomed to repeat it.  Leading change within a project is occasionally necessary to correct inconsistencies, errors, omissions, and/or responses to new issues.  Project management methodology isn’t a “one size fits all” approach and existing business processes may not exactly mesh with what your project is expected to deliver.  Based on this, you’ll need to determine exceptions to both project management protocol and normal business operations.  Challenging the status quo and pushing the boundaries of accepted norms are occasionally required of a Project Manager to get the job done.

 ____________________

“I want a guest to walk into a five million dollar restaurant to buy a five cent hamburger.” – Walt Disney

Lesson Three: Don’t forget about the quality.

Project quality is tantamount to a successful deliverable.  Now, I will admit that the quote above seems a little extreme.  Walt Disney was trying to set the scene for a quality and enjoyable experience within his Disneyland theme park.  You likely wouldn’t want to set this lofty of a quality goal, but you must, as a Project Manager, ensure that every single deliverable of the project meets quality goals and expectations.  The Project Manager walks a very narrow tightrope here.  Exceeding expectations can bring claims of gold-plating, while cutting quality to meet budget, schedule or scope constraints can lead to very unhappy stakeholders.

 ____________________

“It’s kind of fun to do the impossible.” – Walt Disney

Lesson Four: People expect you to fail…prove them wrong. 

Based on the oft-quoted Standish CHAOS report of project success rates (or lack thereof), it is easy to see how some people, including your own project team members and stakeholders, can be skeptical of your ability to successfully deliver a project within budget, time and scope parameters.  Fair or not, the Project Manager is expected to re-direct accolades of project success back toward the team, while on the flip side, accept full accountability when the project fails to deliver on its promises.  How you manage the effort, including the team you are given, the communications you provide, the expectations you set and/or manage and the direct guidance you provide as you lead through issues, risks, milestone checkpoints and delivery acceptance are under your control.  Make informed decisions and direct rather react.

 ____________________

walt-disney-quote1

“You can design and create and build the most wonderful place in the world, but it takes people to make the dream a reality.” – Walt Disney

Lesson Five: Team members make the project a success, not the project manager. 

Putting together a top-notch project team is an essential ingredient to the success of a project.  Over time, project managers have put together teams of technical or subject matter genius, only to discover that these geniuses don’t always play well together.  Ensuring a proper blend of subject matter expertise and a good team dynamic can turn a sluggish project into a streamlined project.  By planning the team structure carefully, before the project is launched, future risk is reduced.  Publicizing reward and recognition programs to promote “above and beyond” effort before the project even begins promotes positive attitudes and fair leadership right from the start.  Equally important, having a plan already in place for correcting and/or negating the impact on the project of poor work or a discouraged and stressed out team saves valuable risk response time for other issues that may arise later during the project.

____________________

“The way to get started is to quit talking and begin doing.” – Walt Disney

Lesson Six: Make meetings more productive.

Project planning meetings, project status meetings, informal project discussions, and the dreaded elevator meeting.  For all of these forms of project communication, preparation and planning are key.  When project team members are sitting in a status meeting, they are not working on tasks needed to reach the next milestone.  Keep this in mind when you prepare your meeting agendas and participant lists.  Does the project team really need to sit through a recap of the tasks closed in the last thirty days?  Probably not, since they are the one’s who closed them!  An effective use of project resource time however, is a half-day workshop early in the project to define key project milestones, streams of work, tasks and time estimates.  Always ask yourself why a meeting is better than other forms of communication.

____________________

“Disneyland will never be completed.  It will continue to grow as long as there is imagination left in the world.” – Walt Disney

           Lesson Seven: Promote and champion change. 

As a project manager, you are, by default, an instrument of change.  Projects do not occur in a vacuum.  Projects are usually created to fix or improve something in the organization and they have stakeholders who are always either positively or negatively affected by the result of the project you are managing.  Simply starting a project can shake up the status quo and make people uncomfortable.  This can bring out the “corporate antibodies” who seek to destroy your project and the changes it may bring.  Change requires clear and effective communication about why the project improves the organization.  Change also requires a strategy for dealing with challenges to the project.

____________________

“I have been up against tough competition all my life.  I wouldn’t know how to get along without it.” – Walt Disney

Lesson Eight: Plan to defend your project.

One of the main responsibilities of a project manager is to defend the integrity of the key project control parameters…scope, schedule and budget.  That isn’t to say that the three tenets of the “project iron triangle” can never be changed.  With proper change management protocol in place, project leadership decisions andor the necessities of  project execution can dictate changes to the original plan.  However, one must always remain vigilant to the negative effects of scope creep, gold plating and risk, regardless of the source.  How many times have you been approached by a project sponsor or stakeholder who demands that you change the project without going through the bother of running the request through the integrated change control system.  If you’ve succumbed to this peer pressure and the project gets derailed, you’ll be the one left without a chair when the music stops!

____________________

“We keep moving forward, opening new doors, and doing new things, because we are curious and curiosity keeps leading us down new paths.” – Walt Disney

Lesson Nine: Innovation can come from inside the project team, not just from the stakeholders. 

Allow your team members to be an integral part of creative problem solving for the project.  By soliciting creative thought from your team members, you foster and atmosphere of innovation, stream-lined solutions, and increased team morale.  Early on in the project life cycle, challenge your team to think creatively about developing solutions to the problem being addressed by the project.  Be accepting to changing plans, approaches and solution ideas.  Run some “proof-of-concept” sessions or trial runs to validate the ideas.  Once the project team has landed on a particular approach however, that is the time to start bringing more control and managed change to the initiative.  Locking in on the tasks needed to deliver a specific approach ensures execution on the idea.  Allowing blue-sky thinking to continue without end causes uncontrollable work effort or worse, “analysis paralysis.”

____________________

 “You know, one day when a little boy asked, ‘Do you draw Mickey Mouse?’ And I had to admit I do not draw anymore.  ‘Well, then you think up all the jokes and ideas,’ he said.  ‘No,’ I said, ‘I don’t do that anymore either.’  Finally he looked at me and said, ‘Mr. Disney, just what do you do?’  ‘Well,’ I said, ‘sometimes I think of myself as a little bee.  I go from one area of the studio to another, and gather pollen, and sort of stimulate everybody.’  I guess that’s the job I do.” – Walt Disney

Lesson Ten: Know when to manage, and when to lead.

An effective project manager must know when in the project life cycle to manage, and when to lead.  Typically, management activities occur during the initiating and planning phases of the project.  The project manager must, by proper protocol, maintain a more “hands-on” approach to guiding the project through the initiating and planning processes.  Defining the project scope, building a charter, developing cost estimates to include with funding requests, preparing stage gate presentations and generating a work breakdown structure with the project team are all direct management activities for the Project Manager.  On the other hand, during the executing and controlling phases, the Project Manager should take a step away from the day-to-day operations of the project and transition into more of a leadership role.  By using a “management by walking around” approach, the Project Manager can allow the team to focus on executing the plan (completing the work) while he/she communicates updates on progress, provides steering/coaching where needed and deals with issues and/or risks that may be experienced.

____________________

So in a nutshell, what are the ten things Walt Disney has taught me about project management?  First, believe in the project one hundred percent.  Second, balance the constraints of time, quality and budget very carefully.  Third, set a positive environment for the project from the very beginning.  Fourth, pay extraordinary attention to detail.  Fifth, walk the project path before ever taking a step.  Sixth, assemble the best possible project team and plan for both achievement and challenge.  Seventh, maintain clear and consistent communications throughout the project and be aggressively proactive in communications with the team and the stakeholders.  Eighth, listen to and understand the unasked question.  Ninth, be certain of project completion criteria.  Tenth, learn from both successes and failures.

Just How, Exactly, Does A Project “Feel” Yellow?

feelingyellow

I was attending a portfolio review meeting the other week where all of the organization’s project managers and IT business line managers are supposed to share project status and openly discuss any issues or concerns.  In reality, it’s a dysfunctional hot mess with sporadic attendance that seems to serve primarily as a forum for people with limited knowledge of project management discipline, or who have no real engagement with the projects, to publicly subject the PMs to a barrage of passive-aggressive questioning and pontification on “best practices.”  But I digress…(in fact, there will be a special post on how to structure effective project review meetings coming soon!)

Anyway, during the meeting, the following comment was voiced,

“I see the project is green across the board.  Based on our discussions here, it feels more like it should be yellow”

Excuse me?  It “feels” like the project should be yellow?  Just how, exactly, does a project “feel” yellow?

A project or key performance indicator either is or isn’t a certain status.  If you are going to use a “stoplight”-based health signalling system in your status reporting scheme, you need to establish EXACTLY what each light color indicates.

For example, here is what I typically use:

  • Overall Project
    • Red = One or more health indicators are Red
    • Yellow = Two or more health indicators are Yellow
    • Green = All health indicators are Green and/or no more than one health indicator is Yellow
  • Scope
    • Red = Unauthorized Scope Change Has or Is Occuring
    • Yellow = Scope change requests pending
    • Green = No scope changes pending
  • Schedule
    • Red = Project schedule variance equal to or higher than 15%
    • Yellow = Project schedule variance within 10% to 14% (+/-)
    • Green = Project schedule variance within 0% to 9% (+/-)
  • Budget
    • Red = Project budget variance equal to or higher than 15%
    • Yellow = Project budget variance within 10% to 14% (+/-)
    • Green = Project budget variance within 0% to 9% (+/-)
  • Issues/Risks:
    • Red = Project cannot proceed due to risk and/or Issue
    • Yellow = Project schedule, scope or budget has been measurably affected by risk and/or issue
    • Green = No issues/risks or issues/risks being managed/mitigated according to plan
  • Resources
    • Red = Project cannot meet schedule, scope or budget without resource(s)
    • Yellow = Requested project resources are unassigned, unallocated or unavailable
    • Green = All requested resources have been assigned and allocated

Project status and other key performance indicators are primarily quantitative in nature.  This is because people’s qualitative observations are subjective, hard to define and difficult to reach consensus.  I’m not trying to completely discount the importance of experience, intuition, reading body language and all of the other soft skills that successful project manager’s leverage when leading the project effort.  But when it comes to reporting, there should be zero confusion on where the facts of the project status rest.  Changing a project’s health indicator because it “feels” a certain way completely ignores the reality of the situation and invites confusion and unnecessary delay.

In fact, the entire concept of a stoplight-based reporting scheme is to:

  • Provide an “at-a-glance” visual of project health for stakeholders
  • Bring a heightened sense of awareness to stakeholders that certain conditions exist which may potentially impact the project delivery (typically for YELLOW status)
  • Call attention to critical issues, risks and/or conditions that have significantly impacted or stopped project execution (typically for RED status)

As a quick side note, a few project stakeholders have asked me over the years why I would flag a project that had a negative variance.  For example, if the project is forecasted to complete a month early, or say -17%, why would that be “bad” news?  Opportunity cost!  In our world of limited resources, people committed to a project cannot be fully utilized on other projects during the same timeframe.  If the project finishes early, what are those people going to do?  The same thing can be said with project financial investments.  Holding onto money that you know your project will never spend robs the organization of the ability to use it for other important efforts…including, perhaps, your raise!