Knowledge Area and Process Changes in the PMBOK 5th Edition

The 5th edition of the PMBOK (Project Management Body of Knowledge) was released this month by the PMI and there are a few changes worth noting.  The biggest change is that there is a new knowledge area called Stakeholder Management.  This knowledge area replaces and expands on two processes from the 4th editions Communications Management knowledge area, Identify Stakeholders and Manage Stakeholder Expectations.  It makes a lot of sense to me that Stakeholder Management would be its own knowledge area.  Stakeholder management is an important and complex area in Project Management and it is frequently discussed in project management circles.  I’m excited to see a focus on this area of knowledge and I look forward to diving into the material in the 5th edition PMBOK to learn the new standards.

Some other changes include the addition to the Planning process group of the Plan Scope, Schedule, and Cost Management processes to the Scope, Time and Cost knowledge areas.  There are also a few name changes to existing processes that improves naming consistency.

Here is are the knowledge areas and processes groups in a table below with the additions highlighted in yellow and the name changes in blue:

PMBOK 5e Knowledge & process table

There are other differences between the 4th and 5th editions but I will not go into them here.  As I continue to explore the new guide I will post what I learn here.  I’d love to hear from you.  What differences have you noted between the two editions and what impact if any do you think they will have?


The Project Manager, Leadership and Trust

As project mangers we are first and foremost, managers.  A simple definition of what managers do is to get things done through people.  There are four activities that a manager performs in order to achieve this objective:

  1. Plan
  2. Organize
  3. Lead
  4. Control

Various sources, such as the PMBOK guide, go into elaborate detail on how to plan, organize and control projects.  Leadership is a different story.  There is no clear guide to being a good leader.

The ability to lead is rooted in the sum of the persons character, integrity and soft skills.  The ability to lead is what sets great project managers apart and it is not a technique. The ability to lead is a part of the art of project management.

Even though leadership is often only thought of from the point of view of the leader, a leader is nothing without followers.  True follower-ship is a choice, and the choice to follow someone is not made willingly if that follower does not trust the person chosen to lead.

Trust is the willingness of a person to be vulnerable and take risks.  In order to do this a follower must see the leader as trustworthy, which requires that the follower sees the leader as having integrity, ability and benevolence toward them.

According to Kouzes and Posner in their book “The Truth About Leadership” there are four behaviors a leader can exhibit to be perceived as trustworthy:

  1. Predictable and consistent behavior. When people know they can count on a leader, then the leader’s words and actions are more likely to influence others
  2. Clear communication. When a leader communicates about an intention, it will be viewed as a promise by others.  Effective leaders are clear about their meaning and as a result, do not mislead.
  3. Promises are treated seriously.  When leaders treat commitments seriously, others do also.
  4. Forthright and candid behavior If leaders are forthright and honest, others will have less reason to be angry or try to deceive in retaliation.

So why is it important for a project manager to have the trust of their teams?  I think this was well illustrated for me recently when a project manager mentioned that they have limited authority over team members because in the end they do not decide their employment, promotions, or raises.  This means that they must lead their teams through influence.

This insight reinforces that project managers, maybe even more than other managers, cannot rely on authority but must truly be leaders so that their team members will choose to follow them.

Tracking Core Knowledge Areas

The core knowledge areas in the PMBOK guide make up the triple, or quadruple, constraint in project management.


from PM Hut

Scope is all of the work involved in creating the products of the project and the processes used to create them.

Time refers to the project schedule and specifically when the project will need to be completed by.

Cost is all about the project budget.  How much will this project cost the company to complete?

Quality has been defined many different ways, one of which is the degree to which a set of inherent characteristics fulfill requirements

When tracking a project the project manager and everyone on the team, should be continuously asking questions throughout the project.  These questions should be focused around the four core knowledge areas:  scope, time, cost and quality.

Core knowledge area related questions:

  1. Scope – Is this in scope?
  2. Time – Is this on schedule?
  3. Quality – Does this meet the specifications?
  4. Cost – Are we under budget?

If these questions are asked continuously then issues that will throw off any of these core project areas will be found and dealt with early.  The key to good project management is to know that you are not done once you have created a project plan.  There will always be change to deal with.  This could be change from evolving customer requirements, changes in staffing, or changes in business due to changing priorities.  Since change is a constant, asking these questions throughout a project can help a team to constantly monitor and adjust for these changes and this can mean the difference between project failure and success.

4 Tips for Managing Your Time on Projects

It can be challenging to manage time on projects for multiple reasons.  There are many different people working simultaneously on a variety of activities at any given time during a project and there are any number of reasons why one or more of them might make demands on you.  Under these conditions it is easy to lose control of your time during the day only to end up working evenings and weekends just to get work done.

Here are four tips for how to get control of your time back:

Tip #1 Purge clutter

If you have piles of papers on your desk, or folders on your desktop, of documents that are a combination of relevant and irrelevant, you may find yourself spending time looking at ones that you don’t really need to deal with.  This could be due to the fact that they are from old tasks that are no longer a priority.  To help manage your time more effectively it helps to take the time to purge your work space of those documents that you don’t need to deal with.

Tip #2 Set Boundaries

Setting boundaries with others is probably the most important thing you can do to manage your time.  From that person who is always dropping by your office to just talk to you endlessly, to issues that are tossed in your lap at the last minute by someone who really should be working on it themselves.  Taking the time to set boundaries with others will help set up good habits for how people treat your time.

Tip #3 Block out working time

Block out time on your calendar for getting your work done.  This will make sure that you have the time you need to complete your work.  It also helps prevent you from becoming overbooked either from your own efforts or those of others.

Tip #4 Block out non-working time

Jennifer Whitt in a webinar from on the topic, “How to Track your Projects” suggests this one and the concept is really insightful.  She said that she often blocks out some time in the morning for things like working out, meditating and planning.  These activities make sure that she is taking care of herself and allows her to set her focus for the day.

If you’d like some more tips on time management I’d recommend watching the hour long webinar mentioned in tip #4.

How about you?  What are some tips that you use for managing your time?

Do You Have Your Blinders On?

As a project manager do you have your blinders on?  It is important when managing a project to remember that your project does not occur in a vacuum.  With everything that needs to be done on a project it is crucial that the project manager and the project team understand where their project fits into the overall business.  Throughout the project, and especially as the project gets more challenging or runs into problems, it will help to keep support for the project high if everyone understands and can communicate how the project will help the business achieve its business objectives.

It also helps to view the project in terms of how it will fit into the overall systems that make up the various business processes that keep the business running on a day to day business.  Understanding how the project will change and fit into the systems of the business will also help with understanding who the project stakeholders are, what possible risks and in evaluating the overall project value to the business.

This concept of thinking of the business in terms of its systems is called systems thinking, and it is a holistic view of carrying out the projects within the context of the organization. Systems thinking is a topic that is near and dear to my heart as Business Systems Analyst.  If you can take the time to define the scope of the system, evaluating its problems, opportunities, constraints and needs you can more easily understand the scope of your project within that system and how it will address them.

Three Step Cure for Controlling Scope

On a project, scope is one of the key components a project manager must control.  It is the component of the triple constraint that most often invokes the ‘project management as art’ description, perhaps only rivaled with the art of stakeholder management.  This is likely because scope  expectations are  really deliverable expectations, as scope defines the deliverables promised at the end of the project.  What customer will not try to get more?  I think it is in human nature to always push to get the most out of a project.

It is also the case that no matter what we plan we cannot see the future. This means that we cannot know all of the opportunities and problems that will arise when producing something new, no matter how many times we have done something similar.  Projects are by their very definition unique.

In listening to project managers discuss scope I have come to realize that some are a little afraid of scope.  The hushed tones and slight trauma they express reminds me of children scaring each other with ghost stories.  Scope creep, or requirements change, is one of those areas that is always challenging in that it has the most potential to utterly destroy a carefully crafted a project plan.  Some project managers respond by trying to shut down all scope changes during a project, but while this can protect the project plan it also can lead to a project that has poor quality deliverables because opportunities were missed during the project.  It is important to come to terms with the fact that changes are inevitable on a project and that the important skill is not in preventing change, but in learning to deal with it effectively.

How to deal effectively with scope:

  1. Make sure EVERYBODY knows the project scope.
  2. Train the entire team to know how to respond to scope change requests.
  3. Communicate, communicate, communicate

Controlling scope is a team effort.  Everyone should understand the project’s baseline scope, what the outcome of the project should be, and everyone on the team should understand how to respond appropriately to a customer request.   The fact is that your team members want to make the customer happy and if they don’t know how to handle requests they may inadvertently commit the team to a change that has far reaching consequences for the project.  It is also critical that any changes that are approved are communicated and documented for everyone to see.

There are many good videos that discuss how to manage scope.  Here is one from Project on You Tube:

Focus on Tim Forman, Project Manager at Renown

I worked for several years with Tim Forman when he worked at NV Energy as a Programmer.  He is fun to work with and I was sad when he decided to move on to Renown.

The good news is, now that he is working as a project manager, I get to interview him for my blog on the interesting work he does now and his thoughts on the position.

Please tell me a little about where you work and about your role as a Project Manager there.

I am a Project Manager for Renown Health in Reno, NV.  My Role is to implement projects for the clinical applications team within Renown’s Information Resources Department.  What that means is that I manage projects for all aspects of the Hospital IT systems to provide process improvements for the teams that care for patients.  I manage everything from IT infrastructure during construction of new units to traditional information system implementations.

What projects are you currently working on, or have you recently completed and how do you feel they have positively impacted your organization and the community?

There have been several projects that I’ve worked on in the last year, but perhaps one you have heard of, and that I’m extremely proud of, is the opening of the New Pediatrics Unit at Renown Regional Medical Center.  We took a very sad 50 year old ICU and pediatrics unit and moved them into a state of the art unit at Renown Regional.  The new floor was brought on line with 100% donated funds and includes many state of the art features.  I was responsible for all of the IT infrastructure from the wiring and networking to the PC’s and 35 networked Playstation 3 units all connected to the internet and Renown’s Medical Record system.  The result is a truly wonderful place for kids to recover, and I sincerely hope no one ever has to spend time there.

What project management methods and/or software do you use to manage your projects? What are the pros and cons of using these methods compared to others you have used?

I’ve used the waterfall approach and have done some Rapid Application Development.  I tend to get caught up in the execution of projects more than the overall process.  I find that in fast pace high volume jobs that the emphasis tends to be on results.  What tends to fall down is a commitment and understanding that projects aren’t driven by desire and will, there is real work that has to happen it’s not just projects schedules, risk management, dates and budgets.  What I find most effective is that no matter what methodology you use, you need to know there is an attainable path to success.  Once you have that path you have to be very focused and ensure that you have the support needed to drive the project to that success.  Without a commitment to achieve the project vision you can use whatever approach you want and you can’t be successful.

What aspects of project management do you enjoy the most?

Finishing and looking back.  There is great joy in knowing you did all you could and achieved what you set out to do.  It’s very rewarding to know you had a hand in every part.  Looking back helps you know where you can get better and how to better manage the future.

What do you find is the most challenging thing about managing projects?

Commitment, understanding and accountability.  It’s very difficult to be visionary and have the right people understand.   Even if what you’re doing isn’t cutting edge or outside of the box, having people buy in and commit at the level you need is very difficult even when they are dedicated to the tasks to support your work.  Ensuring people understand really means that you have to be specific and even when people say they get it, go the extra mile to make sure they do.  When things go wrong it’s very difficult to hold people accountable.  There are a lot of ways to justify mistakes and in the end it all impacts your overall success.  It can be extremely frustrating and painful.

Are there any emerging trends in the Project Management field that you are excited about?

Yes, the tools that people are dreaming up to manage projects, tasks, costs, and resource capacity are incredibly helpful.  I don’t consider myself a gadget guy, but if something comes along that helps me work smarter and better I am excited about it.  People often perceive project management as building a project schedule and yelling at people so your dates don’t slip.  I feel like it can be so much more and if you learn to do it properly.  You can become an area of decision support and optimization for your organization.  Knowing your resource allocations, cost timelines and ability to take on more work can eliminate the intense feeling of being overwhelmed and wondering how you’re ever going to get everything done.

An Introvert at Work

I am guilty.  Guilty of liking those short quizzes that try to reveal something about you.  Most of the time I just think that they are fun, but I don’t take them too seriously.  For as much as it can be interesting to try and isolate some small aspect of the complicated being that I am, and try to analyze and understand it, I know that I cannot truly understand my nature based on one lone observation.  There are so many interdependent factors that make up who I am that labelling myself can be dangerous and counter-productive.  As much as I read about the mind I have come to embrace the theory that I can think myself into a way of being, so I need to work on a holistic and healthy 3-D view of myself not a flat 2-D one.

That being said, and with full awareness of my own fallibility, I do want to talk about the fact that I see myself as an introvert, one ‘personality trait’ that simply hasn’t changed much over the years and which I doubt ever will.  Should I want to change it?  Probably not, but cultures tend to establish preferences for certain personalities and American’s are notorious for there preference for extroversion and the supposed confidence and domineering swagger that comes along with it.  This is especially true in the business world.  I can’t tell you how many times I’ve been told in business classes that executives are extroverts.  The problem with this assertion being, by what measurement?  Is this a self reporting survey?  If so, than these results could be confounded by the fact that most executives would feel pressure to self-identify as extroverts…but I digress.  Perhaps this would be something to look into at a later date.

So, what does it mean to be an introvert these days?  While I think that shy people are likely introverts with social anxiety, not all introverts are shy.  I certainly have plenty to say, and I am perfectly willing to speak up in class or at a meeting if I have something I’d like to share.  It takes a ton of energy for me to do so though.  I really have to push myself and I find myself exhausted after.  This is also the case with going to social gatherings with people I don’t know well.  It takes a lot of energy to turn my attention outward and engage someone with small talk.  One benefit to this is that I probably spend more time listening than talking when I meet someone new.  In fact, I think that there are lots of benefits to being an introvert.  Most of us are happier with what we have, or just being at home with family.  We may only ever get close to a few people but those relationships are often deep ones.  I also spend a lot of time thinking…just thinking things through and I think this makes me a deep thinker and a better problem solver.  I may examine every aspect I can think of when making a decision, but I really commit to that decision once it is made.

This does not mean that my fellow extroverts don’t have close relationships or don’t think deeply, just as being an introvert doesn’t make me anti-social, but I think that we have differnt personality traits because we do get stronger at certain types of functions within our social groups, whether that is bringing people together and lighting things up or thinking deeply, analyzing and listening.

These tips were written in 1999 by Linda Kreger Silverman, PhD of the Gifted Development Center in Denver, Colorado.

Now you might be wondering at this point, what in the world does this have to do with the work place and project teams?  Well, introverts on your team may work differently.  Check out this article, Introverts: Managing stress in an extroverted workplace by Toni Bower. What I love about what she points out is that introverts are more effective in certain environments than others.  If you stick an introvert in a noisy, tightly packed project room day in and day out they will not be as effective as if they have a quiet space that they can retreat to when they need to think or finish a deliverable.  They should be able to work just fine in a team environment but may not enjoy, or in fact may have more trouble blocking out, the constant conversations that are the reality of most working areas where everyone is crammed in together.

Another point that Toni makes is that introverts like to take some time to think and prepare a response to questions that may come their way.  It is more stressful for most introverts to have to address a complex topic or give an update that is unexpected.  I know that I am not as adept  as some extroverts at just making something up on the fly that sounds good.  I want what I say to be concise and accurate.

I think most of us have some idea whether or not we are extroverts or introverts, but I did found a blog post that is a fun read and has a short quiz that you can take to get your extrovert/introvert extremity rating, so check it out.

My rating, well I am only one question off from the most introverted rating the quiz can give, and I’m not unhappy with the result.

What about you?  Are you an extrovert or introvert?  How does this impact you at work and what to you think of your opposite?

Schwaber Google Lecture Video – Scrum Et Al

I just watched an hour long video of a lecture given at Google by Ken Schwaber, one of the co-founders of Scrum given in 2006.  At first I was daunted by the length but Ken is an entertaining speaker and I felt that many of the points he makes are worth hearing.

Here is the video:

Ken starts from the very beginning on the Scrum framework, where the name came from, and then addresses how Scrum either works, or doesn’t given management, the team and the organizational effectiveness or culture.

Here are my notes from the video:

1) Scrum is a method developed from the experiences of those in cross-functional tight deadline competitive environments and was developed through collaboration based on a collection of best practices.

2) During Scrum employees should not be interrupted and should get any resources they need because they were working on something critical for the company.

3) The key aspects of scrum:

  • Everything is a time-box so that things don’t go on forever.
  • Everything is done with cross-functional teams that are responsible for managing themselves.  The best people who can figure out how to do the work are the people who are doing the work themselves.
  • It’s a team that has to have something done at the end of the time-box and can potentially be shipped.

4) SCRUM is used to manage product development.  SCRUM is not a methodology.  If you have a question on what to do you see if it fits in the framework.  There are not many rules but you can find detailed strategies that others have discovered works for them.  It is like chess; how you play it is up to your own intelligence, skill set, etc.  You will know right away if the project is a non-starter.

5) SCRUM frees us from the belief that someone has to tell you what to do in every situation.

6) You want transparency during Scrum.  Know exactly where you are at the end of every time-box.  Even idiots can do SCRUM they just produce crap.  You know if you have a bad team right up front.

7) The Scrum Process:

  • Start with a prioritized list of stuff that needs to be done.  Most important or highest risk etc.  This list is used for starting iterations.
  • A cross functional team of people gets together with the person representing the customer.  This team says how much they think they can do in a sprint.  (his favorite – 30 days) where done  means that the product is ready to be used for that product.
  • Then the team goes off and has a whole period with minimal interruptions.
  • At the end of the period the team shows the customer what they have done.
  • Each team member must exercise their profession competently.
  • The customer must accept the finished work.
  • The process starts again.
  • The process allows you to hone in on your target.
  • A few rules – feedback loop – deals with adapting to complex changing environments.
  • Can’t have feedback without a finished product – can’t have PowerPoint’s of what we plan on
  • Every day the team gets together and makes transparent what they are doing.  Synchronizes the team on a daily basis.
  • It has some rotten things – like finding out the person that you are counting on will not do what they are supposed to do.

8) Burn down – amount of work + estimated + ability of team to transform it into product that is ready to ship = Burndown.  A Burndown graph can predict when the product will be ready.

9) You can tell after a couple of months where the release is heading:

  • The trend can tell you early on if there is a big problem as the trend line will let you know if you are on target.
  • It gets all of the news visible whether it is good or bad.  Intelligent people will want to do the best thing for the organization.  It is a test of the character of the organization on whether they can successfully implement scrum.  Do they have the capacity to handle the news and do something about it?
  • What happens when bad news about the trajectory goes to management?  They ask you to increase your velocity.
  • The assumption is that you can always work harder or you are “not on-board”.  We have time honored conditions for increase velocity – drop quality/cut corners.  Not do unit tests and automated tests.  We can work long hours.  Scrum should have a sustainable pace.  Downtime allows an employee to work on the problem while they are not working.  Longer days increase defects.  Longer hours and cutting quality produces more crap.

10) Common problem with every organization is the lack of support for Core or Infrastructure Software.  On a Burndown chart the developer can develop quickly but the velocity of the core software is very slow.  Core software has three characteristics:  1) it is fragile – change one thing and it breaks other things 2) it doesn’t have good automated test harnesses around it so you don’t know if code changes will break things until it does 3) Only a few suckers left in the company that knows how it works and how to maintain it – everyone else fled.  This lowers the velocity of changing the infrastructure.  New stuff is constrained by the core functionality.

11) The deterioration of quality in software development:

  • If you cut quality than over about five years the velocity will decrease anyway because the code base that you are working from has deteriorated.
  • Book recommendation: The Innovator’s Dilemma
  • Management thinks that they are magic – just ask and it will get done faster.  People will automatically cut quality if they are forced to make  a choice between this and delivering late.
  • Another option is to cut (scope) functionality.  This is management’s other option.  Overall, 65% of delivered functionality is never used, .  Management will be forced to look at what they can deliver that has the most impact given the velocity rather than just giving the team a laundry list.
  • SCRUM is about managing big changes – incrementally, iteratively, through self-managing team and transparency.

12) The Scrum Master (the prick), this person’s job is to make sure that you don’t cut quality.  They have no authority.  If we have defined a certain level of quality then they have to make sure the quality is there.  If the quality isn’t there than you cannot demonstrate it.  They are the least loved person in the world because they stand right at the nexus of product management believing that any amount of stuff can be done and our willingness to cut quality to help them support that belief.  The burnout rate is usually like, 13-14 months.  We get them from hopeless professional areas like QA.  People from QA are used to doing incredible things with no authority, no respect, and no hope of success.  So that is where we take these people. (He is joking here but also serious about QA people making good Scrum Masters).