Calculating Project Value,
Education and Training,
Human Aspects of PM,
New to Project Management,
Nontraditional Project Management,
Reflections on the PM Life,
Categories: Benefits Realization, Best Practices, Calculating Project Value, Change Management, Communication, Communication, Complexity, Education and Training, Generational PM, Government, Human Aspects of PM, Human Resources, Innovation, Leadership, Lessons Learned, New to Project Management, Nontraditional Project Management, Project Failure, Project Planning, Project Requirements, Reflections on the PM Life, Risk Management, ROI
This is a backward blog posting!
This will be my final post before leaving for Chicago tomorrow morning. So, I wanted to do this one more like the way I think about things – BACKWARDS. Instead of telling what areas I can help with, I thought I’d ramble about what areas I like to talk about! I guarantee it would be an entertaining discussion. Just make select an open appointment here: then wander over, say hello and lets just talk about one of MY favorite things.
1. Project failure. I know more than I ever wanted to know about this. There was a group of us that Left NASA at the same time and moved to Orlando to start a company dedicated to turning around troubled projects, programs and operations. When we started, we thought we’d seen just about all the problems that project can get into. WRONG. For the next 5 or 6 years we only worked on turning around projects that were at least 100% over budget, perhaps 3 or 4 years late, had irate customers… or simply failed to deliver anything of value.
It’s not easy to judge project failure! EVA won’t do it. It’s a very subjective thing. “Could anyone have done better in the same situation?” is a basic test, but there are many more.
So, we fired, hired, replaced, improved… bought contracts, had contracts “novated” to us, and were very successful ending up with a stand-along building and 70 employees. There’s a lot of trouble out there! There were project mistakes made that I didn’t think cold be made. We worked on Casino projects, entertainment projects, airline projects, and many other types.
Our group learned a lot! I love to talk about a failed project and how it can be recovered. Number 1: be ready for stress. We called being personally ready “the full wax job.” Exercise, diet, mental toughness, how you dress… no kidding! But you need to be prepared.
2. Working with a team that has widely diverse skills. If the team gets diverse enough, sometimes you can’t understand what the other people are saying. I’ve managed teams with theoretical physicists, mathematicians, brilliant engineers and more – of course, they were totally convinced they were ALL CORRECT, don’t even think about doubting their work. This was great fun. I loved it and learned a whale of a lot about things they didn’t teach me (a humble engineer) in school.
3. Project risk. How to think about it, how to predict it, how to anticipate it, how to communicate it, how to budget for it, how to look for the often-neglected positive risk. It’s CRITCAL that project managers and their teams master this skill. I’ve had friends die a horrible death because we (in a larger sense) didn’t manage risk well.
4. Have the courage of your convictions. Tell people what you believe, tell the bosses what your project team believes. Don’t fall into the trap of “drinking your own bath water” or the “echo chamber.”
Well, I feel better! Wander over and chat with me!
-- Dave Maynard
GOING TO THE 2017 PMI GLOBAL CONFERENCE IN CHICAGO?
Don’t forget about ASK THE EXPERTS!
Stop by and talk to Dave Maynard or one of the other experts. There’s more information about it at https://tinyurl.com/y7ff8f3g
Collaboration seems to be a word thrown around quite a bit. But what does it really mean and why do it? How successful is the practice being implemented? And what avenues are there to do so?
Business has been, always, a form of competition - who can make the most, who can do it first, the fastest, who will own the market?
Often big business drives out the small players, seemingly having lower operational costs by pooling corporate resources, moving to more online, complex data management systems and other such strategies. But is it really a better way to do things?
It's definitely not the only way.
One great strategy is to maintain a specialized focus in business, and then pool small complementary companies to work together to accomplish a larger set of goals. Utilize primary project managers to engage the respective teams in the coordination and collaboration efforts, for all activities required to achieve the goal.
When smaller distinct companies collaborate together on a project, they are forced to engage a lot, to understand the big picture, to be clear about each other's roles and responsibilities, and to understand how each groups' work impacts the others.
There is a greater driver for the lead to have done more research at the front end, to really find and approach the most applicable service or technology providers to work together - those who might bring forward the best potential solutions and flexibility to adapt and integrate to meet the needs of others too.
Such teams work together to assess the whole scope of the project together, to identify the best options and approaches to move forward, to challenge each other and identify improvement and optimization opportunities, and to refine the scope and the objectives or targets of a project collectively.
Perhaps because they don't know each other as well, because the lines of accountability need to be more defined, because each groups' distinct approaches need to be fully understood in order to define all of the relevant risks for that project. Or maybe its because, in order to compete with larger firms, these companies are determined to show great value to their clients.
Whatever the reasons, these projects typically have great outcomes - innovative and unique solutions, better performance and reduced costs for the client.
In the realm of practicing collaboration, we have been shifting ever-more into the use of technology - chat tools, databases and common-use spreadsheets of project information, and project management software platforms of various sorts - where everything can be compiled in one space, including emails, chats, reports, gantt charts, and more.
But is the use of technology helping us to collaborate, or just to consolidate information in one place?
In many cases, our reliance on technology is diminishing our abilities, or willingness, to just get in the same room and talk. Over and over again, PM performance reports surface indicating that we still struggle with:
- visibility of what people are working on, and how far along they are in their assigned work,
- finding information within the system, when we need it most, and
- actual communications, whether that be between teams, or within!
At PMI Global, I'll be presenting about several strategies and tools that can be utilized to get back to basics - true, live, communications and collaboration - in the sense of healthy conflict, co-creation and building on each others' knowledge and experiences, to put the best solutions forward. And to reduce the amount of rework that might otherwise need to be done when we haven't worked in this way!
My talk is titled "The Necessary Culture for Soaring Performance" and I am happy to be sharing these strategies with you, to help improve the performance of your own projects!
If you can't make it to my talk, or if you just have some questions about this that you would like to chat about, I'll also be available at the "Ask the Experts" booth - you can book a 1:1 time with me (or others!) to gain some valuable insights!
Happy travels to all that are coming to Chicago, and can't wait to see you all there!
Regarding a question asked about collaboration strategies and agreements to help make it happen, I noted I would attach a picture to indicate the span of options... not an easy question to answer, but it does occur, so have faith that it can be done!
image produced by Canada Mining Innovation Council
Rethinking the Charter
Calculating Project Value,
Education and Training,
Nontraditional Project Management,
PM Think About It,
Reflections on the PM Life,
Categories: Agile, Benefits Realization, Calculating Project Value, Change Management, Communication, Complexity, Documentation, Education and Training, Facilitation, Human Resources, Innovation, Leadership, Lessons Learned, Metrics, Nontraditional Project Management, PM Think About It, PMOs, Portfolio Management, Program Management, Project Delivery, Project Failure, Project Planning, Project Requirements, Reflections on the PM Life, Risk Management, Roundtable, Scheduling, Stakeholder, Strategy, Tools, Translations
Since I retired after 26 years in one company, I have had assignments in various PMOs in different industries. I’ve been in the energy sector, the insurance sector, credit card services, industrial/manufacturing, and now healthcare. Every industry has struggled with the project charter. What does baselining it mean? Does it ever get updated? Who should issue it? And the list goes on. And while PMOs in all these industries try to invent the perfect process – we are ignoring one important aspect.
The project charter, as defined by PMI, does not meet the needs of today’s business!
Before you call me a heretic and an incompetent – hear me out. The problem I have with the charter is it becomes a reformatting of existing information, bloated, and redundant – and it doesn’t provide the project team with the most important information it needs. Shouldn’t the charter give the team a definition of what success looks like?
I propose the charter should be extremely streamlined. After all, how many people, let along executives, will read a 14 page charter? Many charter templates contain information that is already in one artifact and will no doubt be included in another. I propose we throw away the bloated all-inclusive charter of today and replace it with a simple charter.
Project Organizational Wrapper
You need to have the organizational wrapper of project control structures. If the project pipeline has a defined Demand Process and there is a demand id, it should be in the charter. This should also be aligned to the business case information – what went into the approval, and other justifications. No need to repeat them in the charter – they already exist in a corporate database of record. If information is in two places – that doubles the risk of inconsistency, confusion, and delay.
If you have an integrated project management system (IPMS) that tracks project work in process – then that project id should be there. Projects assume titles and identify from the ideation phase through project initiation. That title, or name, should be included in the charter because that’s the lingo that has defined the initiative.
Should be results focused
Once the project is ready to kick off, the work initiative needs to be focused on the results. If your organization is mature enough to be doing Benefits Management Realization, the charter should map directly to the benefit register. The next section of the charter should be:
What does success look like?
Quite simply – what is the vision in reality? Knowing what success is far outweighs the value of several scope bullet points. The definition of success can be expressed in several ways including:
Critical success factors
The essential areas of activity that must be performed well if you are to achieve the mission, objectives or goals for your business or project.
What can we do in the future that we can’t do now?
How do we measure success?
Not calling for specific key performance indicators here, but should have an idea of how we will measure success. It also provides requirements for the product and what are the critical success factors.
If you are driven by a legal requirement or an industry standard (HIPPA or an ISO requirement comes to mind) than that should be identified. The charter must identify conformation to external factors.
What benefits are being realized?
Again, if you have a mature benefits realization process, then the entire benefits quantification/qualification should be in place and your project is delivering outcomes and capabilities to realize the defined benefits.
The charter must be able to identify all the organizations that are impacted by the initiative. After all, how did you get high level estimates for the business case if you didn’t have a means of identifying organizations involved? This RACI should then be driven to know which groups need to receive and approve the charter.
What time frame is expected for the organization to start to realize benefits? Let’s avoid the charade of bottom up estimates and defining the schedule after you have all requirements defined etc. We are driven by budget cycles and funding is only approved to last so long. This isn’t to say those things can’t and shouldn’t happen, but at a Charter level – the approval has a defined end time. This also helps define the scope.
I have purposely omitted several pieces of what is considered part of a charter. Not that I don’t think they are important, I do, but they belong in defined sections of the project plan. There is no need for budget as that should already be in the business case approval – and I don’t know if it directly contributes to the definition of the outcomes and capabilities. Scope is implied in what success looks like and the Critical Success Factors. If during requirements definition, a question is raised that doesn’t directly support the definition of success, than it is out of scope. Assumptions, risks, issues, and constraints are all important, but they live elsewhere. The charter should identify the future state, not dwell on the challenges of the present state. And the charter should be a onetime document that is not modified or have addendums. It initiates the work – other artifacts ebb and flow during the project life cycle.
In closing – the purpose of the charter is to authorize the project manager to start delivering on the project. It is not to cut and paste from all over to make an all-inclusive summary of all business intelligence that justified the project. I propose to make it a lean document focused on the outcomes and capabilities and the definition of success. Items that have a workflow/life cycle (risks, assumptions, issues, etc.) do not need to be in a charter, they are taken care of elsewhere. A lean, concise, and easy to read charter allows the team to focus on delivering within the success criteria.
Please sign up for a 1:1 with me while at the PMI Global Conference! We can talk about PMOs, healthcare project management, teaching project management, or any other topic related to project management!
To schedule a 1:1, use the SIGN UP button on this page.
I have been contacted by a colleague who has a friend that is pursuing the SP-PMI certification. Is there anybody out there that has the cert that is willing to answer questions for a perspective candidate. If so, please email me at email@example.com.
I would also ask that you put a brief summary of the test content on here, so I can talk a little more intelligently on the topic. I can talk constraint, critical path, slack, lag, float and other rudimentary terminology, but I cannot get into the level of detail that I would expect to be needed to obtain the credential.
I do know one of the biggest challenges in my group is optimizing multiple schedules across projects. Things such as analyzing change across projects, determining impact to benefits realization when schedule slips, and models are opportunities for my education.
I saw this potshots comic today and liked it, so I'm sharing it.
Why do many people (myself included) find it so hard to communicate? I actually find it pretty easy to broadcast (as you can see from my posts), but true interactive communication is difficult. I'm not sure if it's the risk of exposing my feelings, if its a disconnect of values with the person I'm communicating with, if it's my attitude, or if I just don't add anything of value to the person I'm communicating with. Or is could be I'm just overthinking everything :)
Regardless, I frequently challenge my own ability to communicate. Granted, I thought I was a good communicator until I had children, but I found that what I thought I communicated clearly, was not received clearly.
My path to green for this is to keep on trying, Use active listening and watch for body language signs, paraphrasing back what the person said, and accept that I don't have to respond to everything said to me. I can acknowledge with a smile or the nodding of my head.
Anybody else find communication more difficult that it should be?
Get your most burning project management questions answered in “Ask the Experts” at PMI Global Conference. Sign up for a specific time at: http://www.signupgenius.com/go/4090c44a9ad23a7fb6-askthe5 or just stop by.
Times Dave is scheduled for:
Saturday October 28: 3:00PM - 4:30 PM
Sunday October 29: 10:00 11:50 AM, 3:00 5:00 PM
Monday October 30: 1:00 – 2:30 PM
David L. Davis PMP, PgMP, PBA
Senior Project Manager OhioHealth