Hey…Where Did The Project Sponsor Go?

Find

Early on in just about every project, the project sponsor is actively engaged and working hands-on with the project team as the initiative is scoped and planned.  Quite frankly, they should be!  The project usually represents an idea or concept that the sponsor has been looking to execute upon for some time.  Ostensibly, that’s why they are the sponsor.  To get to this point of project initiation, the sponsor has likely had to steer his or her idea through round after round of strategic alignment workshops, budget negotiations and portfolio prioritization reviews.  He/She has a vested interested in the successful execution of the project, and are going to be actively involved to make sure it gets off on the right foot.  In fact, as a Project Manager, you’ll likely be sick of the sponsor before you get to the Planning Phase because they won’t leave you alone to get the work done!

Before we move on, let’s ground ourselves in what a “Project Sponsor” actually is…or should be.  From the Project Management Institute’s Guide to the Project Management Body of Knowledge (PMBOK), 5th Edition, 2013,

A sponsor is the person or group who provides resources and support for the project and is accountable for enabling success.  The sponsor may be external or internal to the project manager’s organization.  From initial conception through project closure, the sponsor promotes the project.  This includes serving as a spokesperson to higher levels of management to gather support thorughout the organization and promoting the benefits the project brings.  The sponsor leads the project through the initiating processes until formally authorized, and plays a significant role in the development of the initial scope and charter.  For issues that are beyond the control of the Project Manager, the sponsor serves as an escalation path.  The sponsor may also be involved in other important issues such as authorizing changes in scope, phase-end reviews, and go/no go decisions when risks are particularly high.  The sponsor also ensures a smooth transfer of the project’s deliverables into the business of the requesting organization after project closure.

But at some point during the project, and it happens in more projects than most are willing to admit, the sponsor seems to disappear.  Sometimes it’s because the project is running so smoothly, the sponsor feels like there’s nothing to do.  Other times, it’s because the project is running so poorly, the sponsor wants to distance him/herself from becoming part of the collateral damage.  Most of time, however, it’s just “out of sight, out of mind.”  Once the sponsor goes through all of the hard work needed to get the project approved and launched, there is a natural tendency to lose intensity of interest.  Most Project Managers, happy to be free of the daily oversight (maybe perceived as micromanagement), willingly allow the sponsor to drift away from being so hands-on in the project as the planning and execution activities get underway.  But this is very dangerous!

What happens if you lose a key resource?  What happens when the vendor that was selected doesn’t deliver as planned?  What happens when executive leadership starts trimming away at the project budget at each phase gate?  What happens when questions come up on how to integrate the project’s deliverables into the line of business?  That’s right, the Project Manager is on his/her own and no matter where they look, there is no ownership for the effort.  So what are your options if this happens to you?

First, contact the sponsor and share your concerns about their lack of engagement.  We all get overloaded sometimes, and that may just be the case with your project.  Or, the sponsor may have such a comfort level on the project that they don’t want to get in your way.  In any event, talk it over and decide how to move forward.

Second, if you can’t get the sponsor to re-engage through direct conversation, they you need to call out the situation as an issue and risk.  Log the details of your attempts to resolve and list the risks associated with a lack of direct sponsor support and engagement.  Alert your leadership team that you are working on the issue.

Third, advise the project leadership team and approval/governance bodies that you may need to stop the project until the issue of sponsorship is resolved.  Many times, the threat to go “Full Stop” on a project or to have the issue escalated up the chain of command will jolt the sponsor back into conversation.

Fourth, and really your last line of defense, is to request that the project be cancelled.  Projects that do not have sponsorship should not proceed.  If no one is willing to own the effort, accept the deliverables at the end, secure funding and key team members, assist with problems and issues or support the Project Manager, the project is on a one-way path to failure and should be killed before it can consume additional resources.

If you are lucky enough to have an actively engaged sponsor, who wants to directly participate in each step of the project, be thankful!  Take extra care of that sponsor.  Overcommunicate.  Form a true partnership.  Become a tight-knit team.  You may still have issues, problems and challenges on the project, but at least you’ll have an active partner and champion for resolving them and exponentially increase the odds of eventually achieving a successful project delivery!

Life-long Learners Make Great Project Leaders

success-learn-lead

There is no shortage of available project management training and continuing education opportunities.  Good thing for those of us with certifications like the Project Management Professional (PMP), which requires 60 hours of “professional development units (PDU)” during the three-year PMP certification cycle.    Most of us will satisfy our professional development needs by showing up at a few chapter meetings, listening in on some webinars and, if we’re really lucky, attending a conference to really rack up the PDUs.

Sadly, much of what’s available for project management education is pretty standard fare.  It’s basically refresher training on the fundamentals of project management using the old, “tried and true” instructor/student format.  Very few opportunities exist that focus on cutting edge project, program or portfolio management concepts.  Nor is it delivered in unconventional ways that help the learner actively participate in the educational experience.

So what kind of alternatives are available?  Did you know that you can earn PDUs* and, more importantly, gain valuable experience and education outside of traditional “classroom” training?  Here are but a few examples:

  1. Project Management Simulation-Based Exercises
    • Project management simulation is an interactive learning activity, frequently practiced as a group exercise. It presents participants with situations and problems that arise in real world projects. The participants can then see the consequences of the decisions they make and can explore alternative courses of action.  Simulation provides an opportunity for learners to leverage existing knowledge, solve typical project problems, make mistakes and analyze the results.
    • Simulations can be conducted on both real projects (to explore various decision options) or hypothetical projects (to practice a certain process or methodology).
  2. Massive Open Online Courses (MOOCs)
    • Online courses aimed at unlimited participation and open access via the web. In addition to traditional course materials such as videos, readings and problem sets, MOOCs provide interactive user forums that help build a community for the students, professors, and teaching assistants (TAs).
      • MITx, Harvard edX, etc.
    • Badge-Based Learning:  Earn virtual “badges” by completing online coursework, exams and other self-study requirements.
  3. General Business Education
    • Executive leaders are constantly clamoring for employees who possess general business acumen.  You don’t have to become an accountant or tax analyst, but having a basic understanding of business models and financial performance gives you a distinct advantage.
    • Learn more about the unique products, services and line of business outputs for your organization or industry vertical.
    • Improve your financial literacy regarding financial management concepts, general economics, financial metrics and reporting.
  4. Soft-Skill Development
    • Project management is blend of science and art.  And lets face it, the “art” is far more important for success.  Anything you can do to build your skills in leadership, communication, leading without authority, negotiation, problem solving or team-building is crucial to your overall professional development.
  5. Agile, SCRUM and Lean Training
    • The latest craze in managing work effort, especially software development initiatives, make use of agile-based methodologies.  Whether its Lean, SixSigma, Kanban or SCRUM, the overall concept is the same, remove the unnecessary overhead, be responsive to frequent change, reduce work into shorter “sprints” and focus on the end result.
  6. Volunteering
    • Leverage your experience and expertise by volunteering your professional services to an organization or group outside of your employer.
    • Serve in an elected officer capacity for a project management organization.
    • The Project Management Institute (PMI) also has many volunteer opportunities.
  7. Teaching/Training
    • Creating a course or developing course content for project management related courses
    • Serving as an instructor for project management related courses
    • Serving as a moderator or subject matter expert of a relevant panel discussion
    • Design and presenting a podcast or webinar
  8. Writing
    • Write project management-related books and articles for professional print or electronic publications.
    • Write a blog for your company or organization

So the next time you are tempted to just half-listen and multitask through a webinar, think about how much of the material you are actually absorbing.  Was it worth it?  Did you learn anything?  Sure, you may get PDU credit, but you’ve cheated yourself out of a valuable opportunity to improve yourself both personally and professionally.  Challenge yourself to learn something new in your field this year or to get engaged as a teacher or volunteer in project management.  Take the initiative to conduct research on developing new, or improving upon existing, project management processes, tools or techniques.  As one of America’s greatest business philosophers, Jim Rohn once stated, “Learners are Leaders.”  Break out of the traditional seminar-based setting and instead, get involved and engaged in your educational experiences.

* Please note that not all of these alternative educational opportunities may qualify for PDU credit with the Project Management Institute or other certificate-issuing organizations.  Please consult directly with the organization holding your certificate for continuing education requirements

The Importance of the Project Hand-Off

Handoff

So you’ve reached the end of the project.  The highlighted date on your calendar that you’ve been anticipating for the past year is finally here.  You’ve herded the cats into the last corral, you’ve wrestled with the scope and pinned it to the ground and you’ve managed to deliver exactly what was promised.  Congratulations!  So now what?  Plenty!

I am not going to mention the lessons learned that you’re supposed to document, but probably won’t.  Nor will I mention the mountain of paperwork you need to complete, file and store.  Instead, I want to focus on the one thing that, if done correctly, will leave the most positive memory in the minds of stakeholders and project teams…the transition from project to daily operations.

There are really three stages (and considerations) for a successful project hand-off:

  1. Project Execution
    • Make certain that all stakeholders are cognizant of the planned completion date so they can adequately prepare for hand-off activities
    • Develop clear and comprehensive documentation of the project deliverables, especially training and/or user manuals such as job aids, quick reference sheets, FAQs, etc.
    • Ensure that the end users of the deliverable(s) of your project actively participate in testing or mock-ups and provide continuous feedback
    • Request a special “hand-off” liaison from the sponsor’s team or the team that will be utilizing the project’s deliverable(s) to serve as a the main transition coordinator and provide input on transition planning
      • Ideally, this resource should be a member of the project team from inception
  2. Project Closure
    • Facilitate a Project Closure Review meeting with key stakeholders to demonstrate the deliverables against the scope and requirements of the project
    • Facilitate a formal Project Closure Sign-Off ceremony to publicly reinforce the transition from project activities to business operations
    • Communicate where the documentation will be located (physically and/or electronically) for future reference
    • Celebrate and recognize individual and team contributions!
    • Draft and distribute a Project Closure Report with all pertinent tracking information displayed as complete
  3. Project Warranty Period
    • Document the rules of engagement for making a warranty (support) claim
    • Make key project resources available for follow-up, Q&A and training as needed per the warranty agreement
    • Hold at least one post-project follow-up meeting with the key stakeholder team to gather comments, suggestions, resolution of punchlist items, etc.

Project Managers who excel at formally wrapping up a project will leave behind satisfied sponsors, confident stakeholders and resources who can look back and be proud to have been a part of the team and have a sense of closure for the effort.  Get this right, and you’ll be a Project Manager that is sought after, appreciated and considered a key member of the organization’s strategic execution team.

 

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!