Skip to main content

Tag: Project Management

The Importance of Process Thinking

Written by George Pitagorsky on . Posted in Articles. 4 Comments on The Importance of Process Thinking

Process thinking is a critical success factor in managing projects as well as operational processes. At a recent meeting, after the term had been used several times, the question “what is a process?” came up.

The answer was narrowly defined as “a documented, standardized set of steps to accomplish an objective.”

Related Article: 5 Steps to Creating a Process-Centric Organization

Every Outcome is the Result of a Process

In fact, a process is any set of steps to reach an outcome. It need not be documented nor standardized. Every outcome is the result of a process, under a set of conditions. Processes exist even when you might think they don’t.

Why Process Thinking is Important

Processes are what add value. Processes cut across functions, departments, and organizations.

The concept that any outcome is the result of a process is fundamental to effective management. Whether you are managing personal relationships, projects, or any operational activity, knowing that the end you wish to reach or have reached is the result of a process enables you to be better at what you do.

If you are looking forward, as in planning a project, it is pretty clear that you will be defining the way you will proceed. You will be defining your process.

Looking back in time, as in trying to figure out how you either succeeded or failed at something you have done, you will be defining and assessing the process that was used. You do that because you know that every outcome is the result of a process under a set of conditions.

You would think this is obvious. Well maybe the idea of planning processes is, though, there are plenty of examples of plans that do not resemble processes. They identify deliverables, dates, and costs without describing how they will be delivered. The process is often left open to the discretion of the performers and defined at the time the work is performed with a focus on silos rather than the process as a whole.

It is a better practice to step back to see and define the process up front; keeping options open for changes that might be needed as real world conditions become known.

The 85/15 Rule

When it comes to figuring out what went right or wrong, there is a common tendency to focus on who did what as opposed to what was done.

Dr. Juran, a pioneer in quality management, described the 85/15 rule. This wisdom says that people making errors cause 15% of problems while process issues cause the rest.

Process thinking makes it less likely that the blame game will be played, or heroes venerated. Instead, analyze the process to determine the causes of problems and successes. Fix the process and the people will succeed in their work. Ignore the process and failures will be repeated.

The best people can be brought down by a bad process.

Conditions of Processes

Processes take place under conditions. The same process may have different outcomes if it is performed by people with different skill levels or cultural norms, or under different temperature or weather conditions.

That is why a well thought out project management process will allow multiple variations to be applied as conditions such as project size, the sophistication of stakeholders and other factors vary. That is why the people doing the work need sufficient flexibility to adapt, moment to moment, but in the context of process constraints.

Attempting to apply a “one size fits all” approach in complex situations is a recipe for failure. Forcing people to follow an inappropriate process is a recipe for failure.

Documented and Standardized Processes

Most processes are neither documented nor standardized. A documented process is one that has been explicitly described graphically or in text. A standardized process is one that has been made common across a number of performers; doing the same thing ion a common way.

People can work towards a common outcome in any number of ways. For example, the members of one department responsible for sales and service in one district may do their job following different procedures than another department doing the same thing in another district. Two teams may achieve their similar project outcomes using different tools and approaches.

The process can be made common so that everyone does their work in the same way, using the same tools and templates, following the same steps.

Why Document and Standardize Processes

Processes are any set of steps, documented, standardized or not. Documented and standardized processes are quite desirable. They are necessary parts of achieving high-quality results.

Documented processes can be analyzed, evaluated, refined, standardized and made repeatable.

According to W. Edwards Deming “If you cannot define what you are doing as a process, you do not understand what you are doing.” If you do not understand what you are doing, you are more likely to do it poorly – inefficiently and ineffectively.

At the same time, the documentation is not the process. The documentation describes the process; it is not the process itself. Knowing this helps performers in complex processes to expect that they should and must not stop thinking, following the process blindly. At the same, time there are situations in which the process documentation should be followed exactly as written. Process documentation should clearly state the risks of following and not following the process as it is written.

Standardized and Repeatable Proceseses

Standardized processes, ones that are used across multiple departments or by many people, make training more efficient, are easier to control and improve and enable easy transfer of people between departments or projects. Standardized processes are repeatable. They can be done the same way over and over again.

Standardization and repeatability are great, but they come with a warning. Make sure they are good. Clearly, you don’t want to repeat a process that is ineffective or inefficient. You need to bring process quality into the picture. In addition, you must consider the conditions and build in alternative paths to address predictable alternative situations.

As said, the best people can be brought down by a bad process.

Process Analysis and Improvement

Define your process. Break it down the steps into bite sized pieces, define expected outcomes, establish acceptance criteria, test it and continuously refine it as it is performed.

Remember, everything is caused by something – a set of steps under specific conditions; a process.

Processes cut across silos. Step back and focus on the steps and the outcome. Establishing roles, responsibilities, and accountabilities is critical. However, avoid sub-optimization — making one department’s process great at the expense of the effectiveness of the whole.

Stop playing the blame game. Critically evaluate your process to make sure that it is as good it can be and to identify exactly where things go wrong and how to avoid repeating the same mistake over and over again. Remember Juran’s 85/15 rule.

Document and standardize wisely.

Take a process view

Done and the Human Condition – Can you Handle the Truth?

Written by Paul Antelman on . Posted in Articles. 7 Comments on Done and the Human Condition – Can you Handle the Truth?

Truth is not the same as “fact.” Truth is an intellectual construct only grasped and pursued by humans on this planet.

Truth is a belief system that is sometimes passed off as a conclusion that is factual and logical from verified premises. It is only the subjective sense of truth, what you believe, that will “set you free.”

I start with this philosophical premise because I think it’s critical in explaining how I have come to embrace the Scrum approach to Agile product development. As a seasoned (read “battle weary”) project manager, I needed to absorb and understand that converting entire development, nay corporate, environments to the Agile way was not simply invoking another silver bullet to rescue them from sub-performing IT systems. As one who has participated heavily in my employer’s course to prepare project managers for their PMP certification, I also appreciate and stay sharp on the foundational principles of running a good project. I have looked at the project management “triangle” as a self-evident truth of most any endeavor that companies launch.

Related Article: From the Sponsor’s Desk: A Moment of Truth

Keeping costs at bay and finishing things on time are constants in the everyday work of the project manager. The ideal, as it has been presented in traditional development environments, is to have a solid road map, well-thought requirements that clearly define the prize at the end of the project. I have done my part in “educating” my clients about the triangle and, in discussing the scope lattice, elevated the importance of “what must be done to provide value.” Scope, and what affects scope, drives risk management, change management, and closure of projects and project phases. The pre-eminence of good requirements elicitation can’t be underestimated, and entire industries have thrived in supporting the business analysts’ tasks to get scope nailed. Measure twice, cut once, right?

Traditionally, project managers have looked at scope as the immutable prize that defined successful projects and truly pleased the client. It works on the premise that the business knows its pain and clearly articulates its treatment of that pain. Projects are chartered that set objectives achievable in a month, 6 months, a year, 5 years, and even more. We do our best to manage costs and stay on schedule, but when we discover that achieving scope will take more, or take longer, we, as project managers, reach into our trusty tool kit of escalation and change control to keep everything on track. I have stayed in this lane for over a decade, shaking my head at those who would speed around me or, worse, get off the highway completely to find the ever elusive shortcut. I can see more clearly now. My treatment of scope has ignored the immutable truth about the human desire for closure, for a sense of finishing what was started. And Agile, specifically Scrum Agile, has shined the light.

Agile turns scope on its head. This is the truth that set me free because I’ve been a disciple (slave?) of scope since my early days in project management. I always go beyond software to defend scope, because I accept the premise that businesses don’t ever totally understand what they want from software. I say, “what about building a house?” If the owner’s top priority is the features of a second-floor bedroom, how would we do that first? How would we apply the notion of incremental and potentially releasable product to a house? So, in my old persona of defender of scope, I shout, “know your business requirements, know what you need, write it down, and test the requirements, the “what must be done to add value””and you might find that you don’t need new software at all. But define that scope and hold it like it’s a precious possession.

Adopting principles as truth goes beyond assembling logically progressive facts into an evidence-based conclusion. You need to believe in the principles and make their truths self-fulfilling prophecies. And this is not a negative imperative because part of the human condition is to make things work in the face of constraints and apparent imperfections. I’ll go beyond that and suggest that getting things done is the most central tenet of the organizational human condition. And guess what? The central tenet of Scrum Agile is getting stuff done.

So the fundamentals of Agile, and we’ll focus on Scrum here, are about getting stuff done. There is nothing more satisfying in the human experience than completing something. Stuff in progress is maddening. The more “in progress”, the less satisfying the human experience. We all say “life is a journey” and philosophers prod us to focus on being happy with “in progress” but our minds contort those journeys, we look for milestones, we look for signs that something is complete. It might be part of a larger thing, but some chunk is complete. This is why the long distance runner wants to know about his splits, why we have “legs” of a journey, why those who simply don’t care about or perceive their progress are likely high or mentally ill. I’m not being flippant here. I think this is true, and I think it is a core truth.

Just as true is the notion that we’re never done with everything that should be done. We’re all Sisyphus, pushing the rock up the next hill, only to watch it roll down. There is no such thing as “done” for a business. It can meet needs, make a profit, and give people a living, but if it doesn’t increase its profit, meet more or unmet, or invented, needs, then it is deemed “unsuccessful.” And this is why we need to be suspicious of scope.

There’s another hill on the horizon. Another set of realities. Are you coming around to accepting truth as more about cosmic beliefs than worldly facts? Agile has. Scrum has, in an elegantly succinct way. That being said, truth is always hard. Scrum is simple to understand and difficult to master (Schwaber and Sutherland, p.3). Difficult? Yeah, like running a two- hour marathon is difficult.

So Scrum is also based on the notion of done. The Definition of Done, as set by the product owner, is the contract of the Scrum Agile “project” outcomes. .If there is merit in my claim that we yearn for a sense of doneness in a world where nothing is ever completely “done,” then Scrum Agile is my highway. But this journey is going to be rocky, believe me. Be humble and realistic in your notion of done. If you take this fork in the road, you won’t produce an inferior product as opposed to the grand rollout of traditional SDLC-produced software. But there will be a learning curve and some painful revelations. It might seem like you’d be better off doing it the old way. Don’t be fooled; don’t listen to those “enjoy the journey” charlatans.

Working toward a progressively elaborated definition of done is a marvelous thing, only appreciated fully in retrospect. Measure what you have and consider how quickly you started making it. The painful phases of “forming” and “storming” have to occur before we get our footing on this tough road.

Scrum is presented as a pure framework; it doesn’t compromise on its core principles. All the constraints that make it less than successful can be addressed by making organizational changes, by transforming the corporate truth proposition. We all know, we all sense, that this is very hard. The real challenge is to convince those who control the purse and see product development goals only on calendars that the truth is about change, and that taking this on means reuniting the seemingly incongruous forces of change with our yearning to get things done. Done, in the new reality, is a to-be-continued construct. Scrum is hard, and tiring, and frustrating in a genuinely Sisyphean way. Hell, I’m not even an Existentialist, and I can’t ignore that rock ascending, only to roll down again.

But it doesn’t mean that we shouldn’t try. It certainly doesn’t mean that we shouldn’t believe in the truth about our quest for done. Colonel Jessep’s quote in a Few Good Men, that “you can’t handle the truth” might be a fact. But you don’t have to “believe” in that and walk away. And if you won’t even try to find the truth, then the truth will never set you free.

References
1. The Scrum Guide™, The Definitive Guide to Scrum: The Rules of the Game, Jeff Sutherland and Ken Schwaber, July 2013. www.Scrum.org
2. “Maximizing Value with Scrum / Agile” two-part course, developed and delivered by Maclore Christensen, CSM, CSPO, November 2014.
3. Camus, Albert The Myth of Sisyphus and Other Essays, New York: Alfred A. Knopf, 1955

Why Social Software Makes Sense for Project Management

Written by Mark Broadbent on . Posted in Articles. 5 Comments on Why Social Software Makes Sense for Project Management

A project is a human endeavour – a temporary society of people with a common interest and a desire to achieve something.

Project management as a discipline attempts to put some repeatable practices around achieving these things. It is forethought about forethought.

The problem is that we project people often get caught up in the process and the artifacts of those processes that we forget to keep our eye on the end-game – the delivery of something for our organizations.

A lot of project management software (certainly in the past) has tried to put some way of supporting a particular process and then sharing the process artifacts with the team in the belief that if we all just see the process artifacts, the project will work. But the big issue is that this way of working still does not guarantee the right result.

Why?

The problem is that I believe our tools often fail in understanding 3 simple principles of human endeavour, especially as they relate to projects:

  1. There is an almost infinite way to achieve something;
  2. Nothing in human endeavour can be totally predictable;
  3. Most often, the big issues that confront most projects are people-related.

To date, we have tried to reign in all of this messy human stuff by following a process – effectively trying to deny the indeterminate nature of most human endeavours – particularly in the creation of something new.

Ironically, it is this indetermination that is our strength.

Through variation and changing influences we humans produce breakthrough results, especially when we need to be creative to overcome issues.

I cannot recall any time when a truly breakthrough change, an “ah-ha” moment, a new product, a creative solution to that seemingly impossible problem, came from having only a disciplined processes. (I’m happy to be proven wrong). There are plenty of examples of competent results being achieved using “the process”, but the new, inventive, brilliant?

I believe that it is simply counter-intuitive to try and achieve a different result using the same process as we did before. It’s certainly hard to achieve something we did last time when the influencing factors change and they nearly always change as time progresses or the environment or people change. It seems that we believe that if we just keep one thing constant – the process – that we will overcome these other variables. The changing environment, changing people and changing influences adds to the indeterminate nature of human endeavours – especially in an ever increasingly complex world.

We humans are essentially adaptive creatures – we take our changing circumstances and influences into account, learn from them (hopefully), and as a consequence, change the way we do things to get the result. However; our processes are often designed to try and ignore this very fundamental nature.

If we work together, draw on each other’s unique perspectives and knowledge we handle indetermination better. The collective mind becomes greater than individual perspectives.

In the process, we move away from thinking of work as a set of transactions or an assembly line of activity that just has to be completed to the process, to thinking and working interactively. When we do this, we achieve something else, something better.
A high level of interaction between team members within a project provides a context for sharing thoughts, ideas, status, issues, events, etc.

This is the secret of social-based software as a tool for projects. Social based software allows for the indetermination of each unique project as a piece of human endeavour to meet the challenges thrown at it by using natural human interaction. This results in a way to achieve our result exploiting the three principles, instead of fighting them.

This process develops a collective consciousness and a shared result with high buy-in. It allows us to handle the unpredictable. It allows us to achieve something in a way that is humanistic, using a variety of approaches.

It does not mean that we have to abandon the good things that our old disciplines provide. It adds a dimension – the dimension that supports the indeterminate nature and the humanness of project endeavours.

Social software in projects is not a panacea to failed projects – but at least it provides an opportunity for success in a way that our favourite project management methods may not – something that supports the indeterminate human aspects of real life projects – people.

And you know – it could just make “work” fun. Because essentially we like to interact, be part of something bigger than ourselves and to be inventive.

Social based software provides us with this opportunity.

Project Management is a lot Like Baking

Written by Kiron Bondale on . Posted in Articles. 3 Comments on Project Management is a lot Like Baking

I love to bake.

Nothing puts a smile on my face faster than the smell of a fresh batch of goodies or the instant, positive feedback I receive from family and friends when they sample the outcomes.

So let’s discover what project management lessons might be learned by stepping into the kitchen.

Related Article: Project Management is All About Trust

Quality in, quality out

You can clearly taste the difference when you bake with higher quality ingredients. Yes, you could bake a cake with cheaper inputs but isn’t the effort you are putting into the exercise worth the greater investment? Arguably, the extra amount spent will provide a taste which far exceeds the incremental costs.

The same holds true when staffing our projects. We shouldn’t settle for lower performers just because they have the capacity. As I’ve written previously, we need our team members to bring capacity, commitment, AND capability – all three attributes are required for project success.

You need to be strategic about resourcing. It sounds great to get a team of all Grade A performers, but a short-lived team of “all stars” is likely to be too costly, unavailable, or would generate more headaches due to ego clashes than the incremental value they would provide.

As with baking, you should identify the one or two key ingredients which will result in a substantial uplift and focus your efforts on securing those.

When baking a chocolate cake, I don’t worry about getting the best quality flour, eggs or butter. But I will favour Dutch cocoa over regular, and real vanilla extract over the cheaper artificial variety. The result of using those is evident with every bite!

Context counts

One size does not fit all when baking. The cake which turns out great when our oven is set at 400 degrees for 50 minutes might still be uncooked when we try the recipe at a friend’s place. Doubling the size of a recipe doesn’t mean you can get away with doubling the baking time – you might end up with charcoal. And finally, the quantities you use of specific ingredients might not scale linearly.

The same holds true with project management.

The complexity of a project does not scale linearly. The reason that Fibonacci sequences are well suited for relative size estimation as the effort involved to complete a work item at higher levels of uncertainty could be exponentially greater than for simple work items.

Practices also need to be tailored to the specific context of a project, the culture of the team, and the delivery maturity of the organization and stakeholder ecosystem. Applying rigorous practices which worked well on a large, complex project to a much smaller initiative is a needless waste and trying to manage a large project with the practices which worked well at lower levels of complexity is professional negligence.

Companies should embrace frameworks, not methodologies. When implemented well, the former provide sufficient guidance to ensure that the right process tailoring decisions get made whereas deploying the more prescriptive latter can often result in the Goldilocks tale of either too big or too small for most of the projects in the portfolio.

Follow recipes until you are safely able to experiment

When I bake something for the first time, I will follow the instructions exactly in terms of ingredients and process steps. But over time, as I get more familiar with it, I can safely begin to experiment by trying different ingredients or approaches. I know that I can get away with reducing the quantity of sugar in my cake recipes or substituting a different liquor when making Amaretto cookies, but that confidence comes with experience.

When we first start to manage projects, it should be the same way. With the support of a seasoned project manager and sufficient process guidance, we should be able to manage a small, low complexity project successfully. On our second project, we will replicate those behaviors and practices which helped us on the first project. Over time, our competency with multiple hard and soft tools will improve so that we can pick the right approach for the specific context of a situation.

But this competency will only come through progressive increases in project size or complexity. Taking a project manager who has been successful managing small maintenance projects and handing them a highly complicated system replacement program would be as foolhardy as asking an amateur baker like me to bake a multi-layer wedding cake under time and cost constraints.

As Tom Douglas put it “If you don’t have the confidence in baking, commit to making the recipe three times. The first two, do it exactly the way I’ve told you to make it. Twice. The first time you’ll screw it up. The second time it will come out pretty good, and then the third time, make your adjustments.”

When we bake, we hope that the outcome will be tastier than just the sum of the ingredients – in that, it is exactly like managing projects.

5 Daily Tips for Successful Projects

Written by Elizabeth Larson on . Posted in Articles. 3 Comments on 5 Daily Tips for Successful Projects

An ad at the end of one of my workout videos caught my attention. A kitchen timer is ticking away. A voice says “It’s about time. Time. Time.”

A trainer appears and says, “The number one reason people don’t work out is time.” A woman appears and says, “I can’t work out for an hour. Are you kidding me? I don’t have time!”i Another ad has a trainer saying something like, “Nobody has time, but if you give me just 30 minutes every day for 21 days, I’ll give you the body you’ve always wanted.”ii Oh were it that easy!

The point is, though, that the world has become a very busy place. Everywhere we go we hear the same message—I don’t have time. I don’t have time to innovate. I don’t have time to manage my project. I don’t have time to get the requirements right. To make time, some people banish project management and business analysis under a magic invisibility cloak (under the guise of doing “Agile”), making anything to do with project management and requirements disappear altogether.

So how do we make time? We would like to propose that if you give us 30 minutes every day, we will give you that project that you’ve always wanted. Here’s how.

1. Track the effort

Tracking? That’s big brother! In project management parlance this is Monitoring and in our opinion, it’s even more important than planning. We know, though, that the very words “tracking” and monitoring” often conjure up images of Big Brother. We can already hear the accusations of “that’s micromanagement.” So let us explain what we mean by tracking.

Related Article: A Plan is Useful Fiction: How Realistic Can It Be?

Tracking involves seeing where we are against where we thought we’d be at this point in time. Tracking can be done formally or informally. It can be a conversation, can include charts like burn-down charts, can include some form of time sheet, or any combination. The most important part of tracking is to take a few minutes every day to see what we’ve accomplished, what work products/features have been produced, where we are now, and most importantly, what issues are getting in the way of getting our job done. We prefer daily conversations. We have found that this type of informal communications keeps people up-to-date and prevents our projects from getting too far off-track.

Having this kind of monitoring mechanism, particularly a visual chart like a burn-down chart, is a great way to report progress. It gives us instant credibility. Anyone can ask us where we are on our project and we know. Such a tool shows on a daily basis where we thought we’d be vs. where we actually are. This can be in the form of a big visual chart posted in the project team area, or the information can be logged in a spreadsheet and sent to various stakeholders. If tracked daily, this information can be easily rolled up into a weekly, monthly, or quarterly report for sponsors, executives, and other interested stakeholders.

2. Plan the effort

Planning? That’s so old school! We’ve certainly met team members who argue that since things change, and since they embrace change, there’s no need to plan. And while if we had to choose between planning and tracking we’d choose tracking, we still believe in planning the work. Daily. We can hear you making a thousand excuses why you don’t have time to plan. Let’s keep in mind, though, that planning, like tracking, can be formal or informal. And the smaller the deliverables, the less formal planning needs to be. Daily planning may simply be a conversation with the team about tasks to complete that day. Taking 5 minutes each day to organize our thoughts will have huge long-term benefits.

3. Monitor the requirements

Old school and big brother! There’s that Big Brother word again—monitor. In our 30 minutes, we don’t have time to elicit, analyze, document, or do anything else with the requirements. However, we do have time to be sure that the requirements are getting to the level of detail needed to get the job done. We can look at our backlog of requirements and review the progress that is being made to refine them—to get big requirements into small features that are defined in a way that is clear to everyone. We can review what is being done to ensure that issues, dependencies, and impacts are being addressed. If the meaning of the requirement is not crystal clear, we can ask questions.

4. Improve

Why?! We already do retrospectives! What we have in mind here is to every day spot problems and opportunities and recommend ways to make either the process for developing the product or the product itself better. Sure it’s similar to what we typically do during retrospectives and lessons learned workshops. The difference is when we spot problems daily, we can quickly prevent bad practices from spreading and a defective product from implementing.

5. Commit

Getting in shape requires other activities beyond our daily routine, and having successful projects involves more than daily planning, tracking, and improving. But these daily activities do make it easier to meet everyone’s expectations. Sure it involves doing things we have little appetite for. No one said having successful projects was easy. Like working out, it sometimes means committing to do what we don’t want to do. As the trainer in the video says, “Not always fun, but we have to do it”iii if we want project success.

i https://www.beachbody.com/product/fitness_programs/focus-t25-workout.do
ii https://www.beachbody.com/product/fitness_programs/21-day-fix-simple-fitness-eating.do?e=460115
iii https://www.beachbody.com/search.do?query=21+day+fix+video

About the Authors

Elizabeth Larson, PMP, CBAP, CSM, PMI-PBA is Co-Principal and CEO of Watermark Learning and has over 30 years of experience in project management and business analysis. Elizabeth’s speaking history includes repeat presentations for national and international conferences on five continents.

Elizabeth has co-authored five books on business analysis and certification preparation. She has also co-authored chapters published in four separate books. Elizabeth was a lead author on several standards including the PMBOK® Guide, BABOK® Guide, and PMI’s Business Analysis for Practitioners – A Practice Guide.

Richard Larson, PMP, CBAP, PMI-PBA, President and Founder of Watermark Learning, is a successful entrepreneur with over 30 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on business analysis and project management topics to over 10,000 participants on five different continents.

Rich loves to combine industry best practices with a practical approach and has contributed to those practices through numerous speaking sessions around the world. He has also worked on the BA Body of Knowledge versions 1.6-3.0, the PMI BA Practice Guide, and the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored five books on business analysis and certification preparation.