Category Archives: Methodology
Just a quick note to say…
I LOVE THIS!!!
click to see it in its full glory
Created by Simple Square. Portfolio website design specialists.
I need the template!
Today I’m inspired by Richard Branson, founder of Virgin Airways.
In providing his best tips for starting a successful business his number 2 is, “Keep it Simple”. He says
“You have to do something radically different to stand out in business. But nobody ever said different has to be complex. There are thousands of simple business solutions to problems out there, just waiting to be solved by the next big thing in business. Maintain a focus upon innovation, but don’t try to reinvent the wheel. A simple change for the better is far more effective than five complicated changes for the worse.”
A simple change for the better is far more effective than five complicated changes for the worse. – Richard Branson
Have you ever been on a project where things changed massively all at once? Sometimes the change is necessary but there’s no denying it wrecks havoc on relationships. I’ve been that PM in the past, the one who wanted it all to go by the book; the perfect project plan, absolutely correct adherence to the SDLC (whichever method we chose) .. and I would push really hard, early on. And wind up being the one who bought in ‘five complicated changes’ that inevitably made things worse.
And it wasn’t methodologically worse; it was relationship worse. The changes were so sudden, they pushed people immediately into taking sides. People never got to really know me as a person, I just became that PM, the one pushing everyone’s buttons the wrong way. I hadn’t learned this truism that really…
…One simple change for the better would have been far better than the perfect methodology (and the 5 changes that came with it).
Now, I’m a little bit more relaxed. I see things every day that I wish I could change, or hear things that make the SDLC-lover inside me want to run for the hills. But…its one thing at a time. Crawl.Walk.Run. I’m focusing my energy first, on appreciating what people are doing, rather than trying to analyze them against a methodology checklist. Second, I’m looking for that simple change that will make things better for everyone.
Here’s one idea from the most recent PM Network A PMO in Kentucky doesn’t force low probability risks into the risk management process. “ ‘We make note of it and discuss it informally.’ Says Janice Weaver, associate vice president of the EPMO at Norton Healthcare. ‘But we don’t spend hours on tasks that don’t add value to our process.’ “
What’s one small thing could you do on your project that would make things better?
Here’s two guys who’ve mastered simple play Simple Gifts..wouldn’t it be awesome to feel like this at work!
I had to get myself unstuck recently and I thought I’d share with you what I’ve learned.
My problem is that pre-project measurement and analysis time is a virtual luxury for small and medium sized firms given the highly competitive environment we are in. And so many projects begin with more intangible, unmeasurable goals than tangible measurable goals. Which means that while success can be obviously felt, seen, touched; it can be hard to prove.
It would be nice to get, for example, ‘approximate processing time for purchase order task completion’ baseline measurements before starting a project. But it’s kind of hard to do when the users sound a little like this: “OMG IF I HAVE TO FREEKIN PUSH ANOTHER FREEKIN BUTTON TO FIX THIS DAGGONE PURCHASE ORDER I’M GOING TO THROW THIS COMPUTER OUT THE WINDOW”
Upon which, the system/powers that be say – OK, let’s move forward with a new system.
And then the PM is now writing up a project charter for the project to get a new system and runs into ‘what are the benefits/capabilities’ to be gained in this system to which they say something like ‘improved productivity’.
But there’s no baseline measure, and so this basic benefit, something really super important to the success of the project, usually remains intangible; something that is felt rather than measured, perceived rather than calculated.
That’s where I’m stuck. Because as the Program Manager I’m telling the PMs, ‘the project will be evaluated by the realized benefits’, and the PMs are saying ‘but the benefit is unmeasurable.’ (which in actuality really means, we don’t have time to do an analysis phase on this thing, we just have to fix the problem).
As an aside, there is growing support for methods used in identifying and tracking benefits. Collectively this body of work is operating under the coinage ‘benefits realization’. I’m incorporating benefits realization into our process. See Thrope ‘The Information Paradox – Realizing the Business Benefits of Information Technology’. And see the Benefits Management process in the most recent Practice Standard for Program Management.
So the question is: Is an unmeasurable/intangible benefit ok to use as project evaluative criteria?
I think the answer is Yes and No.
No in that while we may not be starting with a baseline to compare to for measurable benefits, that doesn’t mean we can’t still define a goal and measure that goal. I think we have to have some type of measurement of benefit or intended outcome for every project.
Yes in that we should strive to be very clear about the intangibles. Even if we can’t measure them, we need to acknowledge them, list them out, clearly state them. The intangibles provide the nuances that can make or break success. For example, I want a car that gets 35 MPG (tangible), but it also has to be cool (intangible).
So the challenge then is how to help project managers identify measurable (tangible) benefits and unmeasurable (intangible) benefits such that even if we don’t have a measurement baseline to jump from, we can at least find some definable goals to reach for, with intangible descriptions to shore up the tangibles.
Here are some helpful things I’ve found to do so.
Clarity on intangible versus tangible
In their book Enterprise Programme Management, Williams and Parr assist with this definition:
“Benefits fall into three categories:
direct financial benefits: those that can be quantified and valued (tangible)
direct non-financial benefits: those that can be quantified, but are difficult or impossible to value (tangible)
indirect benefits: those that can be identified but cannot easily be quantified (intangible).”
Some Tangible Benefits Examples:
- Cost Avoidance
- New Income
- Additional Income
- Reduced Working Capital
Some Intangible Benefit Examples
- Strategic Alignment
- Competitive advantage
- Competitive response
- Improved customer service
- Kick Butt Communications (from my company )
For tangibles, use precise measurement terms
Thorpe suggests using his MEDIC acronym to derive precise language to describe benefits. Instead of ‘effective’ or ‘better’ use terms like ‘maintain’ or ‘increase’.
- M: Maintain – e.g. a level of service maintained
- E: Eliminate – e.g.a function eliminated
- D: Decrease – e.g. turnarond time decreased
- I: Increase – e.g. revenue increased
- C: Create – e.g. a certain capability created
From Information Systems Evaluation Management by Wim Van Grembergen
Finally, we can give easy benefits examples, perhaps in a ‘benefits list’ document.
Here are some examples I’ve found in the field:
I can say that all the projects we’ve done in the past year have had efficiency, productivity, and regulatory expected outcomes, even though we may not have measured where we started from at the beginning. We are now seeing those outcomes come to fruition; as well as perhaps the one intangible that I like but that rarely gets written in a project charter; a happier work environment.
Fundamentally though, I think we still need clearer direction on how to identify benefits. We’ve got good processes for managing benefits, but I would love to see more easily accessible guidance on benefits identification.
Looking for ways to speed up operations on your project?
Think about Releasing the Ownership of Making Changes.
On many processes, there is a Process Owner and the definition of ownership for that process owner includes:
- Ownership of Making Changes
- Ownership of Implementing Changes
Ownership of Making Changes is when the process owner must approve a change before its made.
Ownership of Implementing Changes is when the process owner must approve the change before it’s implemented.
The problem with the Ownership of Making Changes is that it takes longer for changes to happen.
The usual flow is:
Someone (let’s call her the Change Agent) recognizes a need for change
- The Change Agent preps a request to Make the Change to the Process Owner
- The Process Owner gives approval to Make the Change
- The Change Agent Makes the Change, along with all the other stuff she’s got to do
- The Change Agent preps the final change for approval
- The Process Owner gives final approval for the Change Implementation
Ok so, what if we pulled out the need for approval to Make the Change? We’d lose a bunch of steps and gain more time.
That flow would look like:
- The Change Agent recognizes a need for change
- The Change Agent Makes the Change, along with all the other stuff she’s got to do
- The Change Agent preps the final change for approval
- The Process Owner gives final approval for Change Implementation
Now…you can really speed things up by training a group of people to do the work, so that anyone can make the change. If you encourage Change Agents to communicate the recognized need for change transparently, maybe through a collaborative system, then any one of the group can pick up the change and make the change. Assuming that the person who picks up the change did so because they don’t have any other work, they don’t have to shuffle it in priority with other things on their plate. So the work gets done faster.
That flow looks like this:
This idea is why Kanban and Agile teams get things done faster.
To really make this work, the Change Agents must be people with the skills and training to make the changes. Ensuring that you have a key skilled group of people provides a measure of confidence to Process Owners and prevents chaos when making change.
The Process Owner must still approve the change, which also prevents chaos. You should also create some type of way to rollback if the change is not approved or a place to make visible and shareable drafts.
Try this on a small process and feel it out. You may find that Removing the Ownership of Making Changes results in large, beneficial gains in productivity.
I believe that in a few years time, the Project Manager as we know it, will go away. There will be hold outs in slowly changing industries (defense for example), but on the front edge of the economy, in the newer industries, the Project Manager is going away.
This is something to take note of – it doesn’t mean that we Project Managers will no longer be useful. It means that in order to hold our jobs, we have to adjust our thinking, our paradigms, about our role in relation to others and about the value-add we bring to any organization.
Manfred Saynisch’s article in the PM Journal talks in detail about this upcoming shift.
I’m starting to see things differently because of it. I’m starting to see my role differently because of it.
This is a long post. For those who don’t want to read, I’ve summarized in these bullet points:
- Traditional project management methods are failing due to the complexity of the systems in which projects find themselves.
- To be successful, Project Managers should start to adapt to complex systems; moving from controlling to influencing.
- This is a difficult, but necessary change and expansion of the Project Management role.
Traditional Project Management Vs. Complexity
Manfred Saynisch is the key author of Project Management Second Order (PM-2), a new framework of thinking about Project Management that was published in the Project Management Journal in December 2010.
Saynisch explains that projects are goal oriented endeavors that operate in a context of larger self-organizing, evolutionary systems. These larger systems are evolving at their own pace.
For example, a small company (the ‘system’) progresses towards its goal at a pace that’s influenced by many causes, both internal and external. The pace resembles evolution, with gradual growth, occasional shocks that send it shooting off in one direction or another. A complicated network of interrelationships influence this context, and put the stops on it, or send it careening forward. Different entities within the organization have different stocks* of power and energy and thus the company organizes, and then re-organizes (self-organization) based on all these things. Predicability, even in smaller companies, is really difficult.
Enter the Project Manager who has been taught to develop a schedule, to control all the internal and external forces, or at least manage them so that the goal can be reached.
Our methods usually employ single cause controls (such as controlling for individual risks and issues, or stakeholders), and assume a linear time progression to the project which we capture in a schedule. We seek to aggregate the amount of time it will take to accomplish tasks, so we can estimate finish times, and to start and stop the processes just when we need them to. The methods operating in the project are a far far cry from those operating in the system that the project finds itself in!
Inevitably, we bump against the self-organization evolutionary methods that exist in the system.
We call them corporate politics, or the market, or commodity prices, or new home starts, or consumer confidence and we evaluate who has certain stocks of one thing or the other – who has influence and power, for example, in order to try and control how the system affects our projects.
Sometimes we are successful. A lot of times, we fail. We fail because the system is moving at a rate that doesn’t work for our project, the self-organizing, networked, multi-causal system will not bend to controlled methods, such as schedule management, issue management or stakeholder management; methods that evaluate single objects and seek to influence those objects independently, without analysis of the many many environmental influences that object is subjected to in the system.
Yes – its complicated. Actually – it’s complex.
The New PM Worlds
Saynisch’s model introduces a new way of thinking about Project Management. He is suggesting that the way in which we currently manage projects, which he calls PM World 1, Traditional Project Management, is characterized by the following:
- A Project Manager external to the system
- A Project Manager seeking to implement controls on the system
- A sense that there is a linear, logical progression to events
- A sense that objects in the system can be controlled through various methods
- A belief that there is usually one cause, and therefore one effect. Control the cause, and you control the effect.
World 2 is about acknowledging and understanding the complexity of systems. He calls this world ‘Complexity Management’. World 2 is characterized by the following:
- A Project Manager who is inside the system
- A Project Manager who influences the system, rather than controls the system
- A sense that events are evolutionary and non-linear
- A sense that objects in the system have their own flow and organize themselves
- A belief that there are multiple causes and therefore multiple effects. And that you cannot control most of it.
The future, Saynisch indicates, is in the ability to develop processes that mimic the self-organizational, multi-causal flow of complex systems while simultaneously accomplishing the goals of the project. Its about encouraging the development of patterns and self-organized structure, gently nudging the system toward the goal, rather than enforcing rules and applying structure.
We must migrate from EXTERNAL CONTROLLER OF EVENTS to INTERNAL INFLUENCER OF PROCESS
Saynisch also proposes 2 other PM worlds. World 3 – The universe of Human Behavior and World 4 – The universe of Ground Rules and Ways of Thinking. These are important to explore as well, but I’ll save that for another post.
World 1, Traditional Project Management, doesn’t go away in this new model. Instead, World 1 provides the description of the system. Traditional Project Management is like the glossary where you learn; what is a Stakeholder, what are Activities and how do they work together, what is a Risk. Traditional Project Management knowledge is also a how-to manual and toolkit that are used to influence the system. Traditional Project Management provides the tools and knowledge to know how to build the processes.
And World 2, Complexity Management, encourages the PM to think about building self-sustaining systems and processes, where people are provided the tools for self-management, where actors are taught to reference principles for self-guided behavior, and where processes are networked intelligently to produce desired outcomes.
He writes “Finding the proper balance between complexity and traditional management will be the future management art.” page 8 Project Management Journal, December 2010
Finding that balance is more than just a bit hard. Its daggone difficult. But, and this is why I’m even writing this post, I think it’s the only way to build really good projects that work in the future.
The difficulty comes in on a personal level. When you are used to acting externally on a system, when you are used to the control role, letting go of it can seem like a career killer. The difficulty also comes in on a method level. In this new view the methods that are the most important; the ability to influence, the ability to strategize, the ability to think in systems, the ability to encourage the adoption of principles in others, seem nebulous. Where do you learn that?
And not only is this difficult, there’s indication that Its also the way to keep your job.
I don’t know about you, but this article Google Facing a Significant Reorg with Managers on the Firing Line scared me. It read to me like Google was eliminating pure Project Managers and indicating that they had built internal self-sustaining structures and principles such that people managed themselves.
“Google will be moving away from a structure with centralized managers and towards a structure where engineers run individual units.”
Witness as well, the rise of Agile, where the PM provides influence and direction from inside the system. The team decides the schedule, and that schedule is not wholly predictable from iteration to iteration. Agile has built in acknowledgement of the multi-causal, dynamic, non-linear system. Or Kanban, where teams of people set up systems that reveal bottlenecks and are encouraged to solve them together as a team. No pushy PM needed.
Maybe this is why Forrester analysts are suggesting that the “Next Generation” Project Manager have both World 1 and World 2 skills.
Mary Gerush writes “Next-generation project managers still have a sound understanding of project management best practices (pm world 1), but they also have updated soft skills focused heavily on people, team building, and collaboration, and they understand how and when to adapt processes, practices, and communications based on context (other PM Worlds)” Mary Gerush, Forrester, Define, Hire, And Develop Your Next-Generation Project Managers
You may be saying to yourself ‘What’s the big deal, soft skills have always been a part of Project Management?” What’s different is that this is not just about soft skills (as in getting along with people), but about migrating from external controller of events to internal influencer of process “based on context”.
Does the Google example indicate what’s valuable on the market? I think so and I think it’s this.
In the new world, the ability to influence a self-organizing system to move in a more effective, productive manner is more valued than the ability to bring in projects on time and under budget.
Influence not control. It’s about understanding that your goal is to apply what you’ve learned in your PM toolkit towards the development of processes that both incorporate good PM methods, but also can sustain themselves without you.
For example, instead of building a change management process that starts with a change management plan leading to a weekly meeting of a change control board, you instead seek to define the effects that certain changes will have on the system. You then train the team to recognize these effects so that they know a change is needed. You then encourage them to decide on changes based on the principles you’ve taught.
In this example, Traditional Project Management tells you that changes should be managed. That’s the influence of World 1. Then in a very World 2 type of way, you build a process that communicates the ‘why’, that teaches change management principles to the actors in the system, and then allows the system, the teams, to self-organize and decide on how to use the principles. It’s expected that in this new milieu the original principles will evolve. So what you’ve really added in then, is the thought ‘changes should be managed’, which derives from World 1. But you’ve released the ‘how’ to the system and by release, you also allow the idea to evolve to what the system can handle and resolve.
For anyone who plays the game Osmos on the Ipad, you can see this in action. The balls move in a complicated dance and you, the player, are the nudger in the system. You are trying to reach a goal and the only way you can succeed is to gently nudge and push objects that are already moving. This game is not about lining up the balls in an assembly line – its about observing the system and knowing how hard and how long to push.
Take a minute to watch the Osmos video to see what I mean.
I think it’s important to give this some thought. Figure out what skills you bring with you from World 1 and then think about where and how you’ve practiced World 2 skills. Think about those times when projects have gone completely off the rails and what skills you used to bring them back in. Think about the processes you built to prevent that from happening again. Think about the teams you’ve mentored to do great things, and how you influenced them, and what remained, what was sustained after you left the project.
Within this thought process, you’ll start to find your skill set, those areas where you are strong. You might then start to focus on those areas in preparation for shifts in expectations about your role that I believe are sure to occur.
* For more on Systems and stocks, read Donella Meadows Thinking in Systems: A Primer