Ruminations on Change Control October 22, 2014Posted by Edwin Ritter in Project Management.
Tags: Change, change control, process, project deliverables, project experience, project management
add a comment
It seems that no matter how much project experience you have, how talented your team is and how simple or complex a project is, there is one thing that will always be constant and that is change.
Previous posts of mine have dealt with setting up projects, closed loop feedback and the value of PMOs. Another basic process to define and get agreement on while setting up a project is how to handle change. The concept again applies to ITIL, Project Management and Lean Six Sigma areas. The level of process to use in review and accept/deny changes can be proportional to the complexity of the project. Simple projects don’t have many changes while complex projects can have multiple changes. This relates to the fact that we make decisions and plans at a point in time. As the project goes forward and we get smarter in the future, we may need to revise our plans and that can lead to change.
In fact, during the planning phase, the process details should be documented to submit a change, review and assess the impact to the project. There are as many ways to deal with change as there are organizations. Having a consistent way to deal with and manage change(s) to a project is essential when change occurs. This chart illustrates the basic concepts as just one example of the process. Using a common repository, change log or application to create the change record is a good practice also.
The PM works with the project team to provide an impact assessment and a recommendation on the change. That decision should be reviewed with the sponsors. Each change should be assessed for impact to the schedule, resources and budget. Here are six steps to control change:
- Record / Classify – capture the request and indicate what area(s) of the project are affected
- Assess – review the impact to the cost, schedule and resources to implement
- Plan – update project documents as appropriate based on the assessment
- Build / Test – execute the change and determine effect to the rest of the project deliverables
- Implement – include as part of the project deliverables and release at go-live
- Close / Gain Acceptance – complete the documentation on the request and communicate with the team and stakeholders.
Using the process framework provides a way to control changes for a project and the rate at which changes are generated. Here is where the process helps in that it provides a way to accept or deny changes. Completing an assessment of the change and updating plans result in data to support the resolution to the change request. Not all changes are created equally. Some can be rejected outright and from other requests, it is clear to see the benefits.
Last, during project wrap-up and lessons learned, the number of changes submitted and their resolution can provide some interesting insights. How many were submitted? Accepted? Did the changes requested indicate a gap with requirements? Was the project not planned properly? Was the design not fully thought out? Those questions and others can lead to animated discussions. The key is which ones to action and improve on going forward.
Of course, that could be a change request also. How do you manage and control change? Does the process impact your project in a big way? What happens if you reject a change? Comments invited.
Ramblings on RACI Matrix for Projects September 25, 2014Posted by Edwin Ritter in Project Management.
Tags: ITIL, matrix, project management, project manager, RACI, RACI matrix, six sigma
A lot of things need to occur to get a project started. For the project manager, understanding the basics about the project – the goal, timing, budget are some of the tasks to getting organized. Included in that understanding is who will do what tasks for the project.
A great way to get organized and develop that overall understanding about the make up of a project is to document. No, really, it is. There are several basic documents that come to mind. As separate and distinct files, those include the scope, charter, schedule and raci matrix. Each of these is important for upfront planning and also during execution of the project. I have found that writing or contributing to each of these is very helpful. Being able to communicate the knowledge of the what, how and who during a project kick-off meeting helps get the team up to speed quickly. Most of the documents are easy to understand conceptually by their title. The last one, the responsibility matrix thing, might be a bit unclear.
Essentially, the raci matrix lists who is responsible for what on a project. As an acronym, it stands for Responsible, Accountable, Consulted and Informed. A brief definition of each will assist in why this document is useful for the project manager, the team and stakeholders.
Responsible - Those who do the work to achieve a task. There is typically one role with a participation type of Responsible.
Accountable - Those who are ultimately accountable for the correct and thorough completion of the deliverable or task, and the one to whom Responsible is accountable. Typically, the Process Owner is Accountable for a process, and there must be only one Accountable specified for each task or deliverable.
Consulted - Those who are not directly involved in a process but provide inputs and whose opinions are sought.
Informed - Those who receive outputs from a process or are kept up-to-date on progress, often only on completion of the task or deliverable.
There is a variation that includes another role for support. There are templates available for a RASCI as well. The ‘s’ stands for support and the definition is :
Support - Resources allocated to Responsible. Unlike Consulted, who may provide input to the task, Support will assist in completing the task.
The RACI matrix is not only used in project management. It is used in other IT processes and methodologies. The RACI matrix is part of the ITIL process for service design and driving service improvement. For Six Sigma methodology, the RACI matrix reflects the basic principles of the process.
Having a RACI helps everyone understand the specific interactions and dependencies involved with the who and what on a project. The RACI matrix is useful for communicating across the organization when a project needs support. This can be very useful in matrixed organizations and reduce the overall time required to get resources.
On this sample, you can see the project manager is accountable for almost everything. Additionally, you can see what each person on the team owns and will drive to completion. A subtle point here in that it also indicates what tasks each person should plan, be involved with for, or otherwise be aware of. From my experience, it also visually emphasizes teamwork and that a team effort is required to deliver the project. Note – the astute among you will notice that the example matrixes shown in this post are transposed. However they are oriented, the concept remains the same.
Comments invited on this tool in project management, ITIL or Six Sigma.
Ruminations on work life balance August 22, 2014Posted by Edwin Ritter in Behavior, Grab Bag.
Tags: leadership, management, time off, vacation, work life
add a comment
Labor Day is right around the corner as we approach the end of another vacation season. Taking time off is an important part of the balance between work and play. Going on vacation is beneficial for multiple reasons and mental health is a primary one. Companies like to proclaim how important employees are and that having paid time off (aka, vacation) is a benefit they (sometimes grudgingly) provide. We all look forward to the annual summer sojourn to a familiar place. Or, the thrill in going to new places while taking time off.
So I find it interesting the strong reaction people have when the media reports our elected officials have vacation plans. Not only plans, but, actually going on a trip for vacation. The shock, the disappoint from people when a state senator, city mayor or even the president takes a few days to recharge.
Why are we surprised by this? Do we really expect politicians to work all the time? Of course not. However, there is perhaps an unrealistic expectation that a politician will stay at work during a crisis or when there are lots of events that may require their attention.
Consider the furor from two recent events. One involved NYC Mayor, Bill DeBlasio. He and his family planned a trip to Italy. The timing of this trip upset many residents who use mass transit. The nerve of him planning to leave the country while there is the threat of a transit strike. He should be at work!
A second event involved the POTUS. Aka, the President of the United States. Critics state he should not go on vacation while there are issues in Ukraine, Middle East and Ferguson, Missouri. He needs to be in the oval office. Taking vacation now is in poor taste, shows bad judgement.
Hold on. Everyone likes to go on vacation. We eagerly look forward to taking time off. Studies clearly show the benefit in maintaining a work balance with life outside the office. This applies to everyone regardless of their job. Also, our elected leaders are never really out of touch with current events. Not anymore. They may not be in the office yet staying connected has never been easier. Politicians, like the rest of us, can and often do, work remotely.
Taking a few days off is not so dire. Consider a vacation from 1927 with then President Calvin Coolidge. He and his wife spent three months in the Black Hills of South Dakota. Three months! Taking that amount of time off today is unthinkable. How times change.
Great leaders can, and should, delegate effectively. When done well, we do not notice a difference. How many times has a co-worker post poned vacation plans to stay at work? Was it really necessary? I say, enjoy your planned vacation and let our leaders do the same.
By the way, how was your summer vacation? Do anything exciting?
Enjoy the long Labor Day weekend and the time off. Comments always invited!
SMART Requirements July 9, 2014Posted by Edwin Ritter in Project Management.
Tags: assumptions, process, project management, requirements
add a comment
I’ve been ruminating lately on the interplay of the following : assumptions, requirements and expectations. Whenever we interact, being a good listener and confirming what you heard are key to meaningful conversations. Segue to a snippet of dialogue from a favorite movie scene :
Man: “You’d better tell the Captain we’ve got to land as soon as we can. This woman must be taken to a hospital.”
Woman: “A hospital? What is it?”
Man: “It’s a big building with doctors and patients, but that’s not important right now.”
Which reminded me of SMART*. A quick search led me to this blog which captures what I agree with on the having clear, defined expectations and the big ‘R’ word, requirements. It should not always fall to the project manager to sort this out of course. Sponsors and customers can be SMART. Wouldn’t that be nice? Which implies process and management styles – a topic for a future post.
*Common definition for SMART: Specific, Measurable, Actionable, Reasonable and Timed
How often are your projects SMART? If you asked for that as a requirement, what are your expectations for a response?
Originally posted on The Practical Project Manager:
In my opinion, requirements are the most under-rated aspect of most projects. In an unbelievable number of corporate projects they are completely non-existent and in the vast majority they are really no more than a paragraph or two of high-level requests which are unlikely to be delivered on successfully. In a very few of the countless projects I have worked on I have seen adequate, or an attempt at adequate, requirements. These projects, without fail, are the most successful projects that I have seen.
Why the passion, you ask? Without clear, complete and agreed upon requirements there is almost zero-chance, yes zero, that the project will be delivered successfully. And when I say successfully, I mean on-time, on-budget and matching the desired scope. Sure, most projects will get delivered without good requirements but you will see project delays (possibly numerous), budget overruns, and final scope that doesn’t satisfy the customer…
View original 1,658 more words
Fake Bestsellers, Concern Trolls, and Hidden Agendas June 26, 2014Posted by Edwin Ritter in E-Commerce, Trends.
Tags: digital publishing, long tail
add a comment
An example of the long tail with digital publishing. Several lessons learned here for authors to be aware of and worth the read. Article details the process and some publishing realities in a niche of a slice of a sub-topic. Also, having realistic expectations is examined here as well.
Originally posted on David Gaughran:
Last Friday we were treated to a story from the Op-Ed pages of the New York Times, where Tony Horwitz claimed “I Was A Digital Bestseller” then complained about how little money this made him, and how he would now stick with traditional, print publishers as a result.
Then this Op-Ed was held up – in outlets like Gawker – as another example of how writers have it so tough in this scary new digital world which is going to lead us all into penury.
Just like the story I wrote in January – Fake Controversy Alert: Hitler’s Mein Kampf Was Not A Digital Bestseller – the key “fact” in Horwitz’s tale of woe doesn’t hold up to scrutiny.
Can you guess what it is?
View original 1,990 more words
Memorial Day, 2014 May 24, 2014Posted by Edwin Ritter in Miscellaneous.
Tags: holiday weekend, honor, memorial, Memorial Day 2014, service
add a comment
Thanks to all those currently in active service!! We are proud of you and appreciate all you do for us. For those returning to civilian life, I hope your new normal works for you and those around you. Peace.
Ramblings about PMOs May 15, 2014Posted by Edwin Ritter in Project Management.
Tags: PMO, project management, project management office
In my recent past, I heard our company management question the value in having a PMO. My understanding has always been that the primary reason a PMO exists is to define and maintain standards for project management. PMO is the acronym for Project Management Office. The bottom line result in using a consistent set of standards and practices maintained by a PMO is reduced costs in delivering projects to the customer (internal or external). Often in establishing a PMO, the templates and supporting processes are tailored to suite the organization and culture. When done right, the value is easily understood and there is a proper balance of process, overhead and execution.
I recently came across two appropriate graphics from another blog that show what a PMO does. A shout out here to the Project Management Files blog here as the source for these images. I submit they quickly depict visually what the PMO can do. The image above shows the PMO transitions involved with the queue of potential projects, active projects and the archive of closed/completed projects. There are many tools to manage these transitions. How to evaluate a candidate project for approval is related to ITIL and of course, the management style. Also related to my previous post on being data driven.
Another value the PMO provides is with managing the project portfolio and programs. From the same blog, this 2nd image shows how the portfolio, program and projects are distinct. Notice how as a planning tool, this portfolio view can easily be used as a roadmap. In terms of communications with a project team, a PM group or PMO stakeholders, having this overview of projects and interplay among program and the overall portfolio should not be underestimated. It is a much easier discussion to adjust timing of any project and then sort out the impact later. Together these two images provide a great educational tool to ensure everyone understands how projects will be deployed/evaluated/resourced.
Im my journey as a project manager, I have contributed to PMO standards and practices in several organizations. I appreciate the value in having those standards and consistent process to drive projects. The value comes in everyone knowing (and, agreeing on) what is being worked on across the organization and when it will be delivered.
At least one management team did not see that. They had but to ask to find out.
What does your organization use? What is used to manage projects? Does it have a PMO?
Making Decisions with Data March 25, 2014Posted by Edwin Ritter in Miscellaneous, Project Management.
Tags: data evaluation, decision matrix, decision process, Kepner-Tregoe, root cause, six sigma
add a comment
How familiar is this phrase “We are going to be data driven”? I have heard this a few times in my career. Great concept and useful to manage a business if you are serious and use it consistently. However, when crunch time comes, and everyone’s nerves are worn thin, how many managers stick with the data vs. using their instinct to make a decision?
No one intends to make a poor or bad decision. Assumptions can be wrong; risks occur that are not foreseen. It happens.
The concept is obvious of course, but, one of the most effective ways to make a decision is to use solid data. What is not obvious is the process to define, collect and evaluate data to make an informed choice. Other real world considerations like time, money and deadlines may circumvent staying true to a data driven process.
All things being equal and when there is adequate time, the process I most prefer uses selected weighting on a set of criteria. The process is commonly known as root cause analysis as a decision making method. Most refer to this process as Kepner-Tregoe analysis. It is named after the two people who invented the concept and today, their company is a multi-national consulting company. This method is one widget in the Six Sigma toolkit and is considered part of ITIL practices for problem management.
An overview of process includes :
- State the issue, problem, and decision to be made.
- Explain the use of the decision matrix technique to participants.
- Draft a matrix … with candidate choices positioned as rows and criteria as columns.
- Weigh the criteria, if required (e.g., 1-5 weight).
- Rate each choice within each decision/selection criteria (e.g, 1-5 score – do not rank here).
- Multiply the rating by its relative weight to determine weighted score.
- Total the scores.
- Review results and evaluate, using common sense and good judgment.
- Reach consensus.
Once complete, you have criteria and weighting configured in the decision matrix. When evaluating choices, the score helps narrow the discussion to the best choice(s). The discussions on reviewing the results can lead to animated discussions. Ultimately, the best choice comes down confidence in what the numbers tell you. I like to include a tie-breaker or ‘other’ category in the matrix and give it a small weighting of 5 to 10%. That allows a way to include intangibles discovered during the evaluation. Depending on the score for that facet, it can illuminate the best choice and help the team decide between two otherwise equal choices.
This evaluation process can be used for a range of situations where decisions must be made. I have used this for vendor selection, candidate interviews and for strategy roadmaps. In the end, having data can confirm your choice and give confidence. Using this framework also minimizes biases and leads to an improved appreciation of choices you would not have considered otherwise. Having data is always good; having a process to make a choice with that data is even better.
What process do you use to decide?
Impact of Project Communications February 25, 2014Posted by Edwin Ritter in Project Management.
Tags: closed loop, communications, feedback, hearing, listen, management style, project management, project manager
1 comment so far
One of the most important skills I find in project management is being able to communicate. It may sound simple and a bit obvious and yet can be a hard lesson learned for project managers. My experience has shown that having the ability to hear and, just as important, be heard, can make or break a project. The format and style used in those communications can be formal or informal, relative to the culture and management style of the organization. Regardless, that ability to indicate progress or raise issues quickly and get feedback keeps a project on track and moving forward.
In fact, I prefer having a closed loop in communicating. I have found that the feedback loop is key to keeping everyone on the same page about a project. This works not only during execution but also for change management. Without feedback, you may not meet the needs of the client and/or stakeholders. That is a waste of both time and money for them and you. That can easily be avoided working in a closed loop with feedback.
- Listen to both what is said and what is not said.
- Build relationships with everyone involved in the project and across, up and down the organization.
- Set clear priorities with the team and obtain that list from the stakeholders.
- Collaborate with everyone as none of us is as smart as all of us.
- Convey the mission and project impact to it.
I agree with this list and also expect that stakeholders have similar skills. Their ability to listen and provide clear direction is a key success factor on every project.
Without feedback, how would you know you when you successfully deliver a project?