You can use whatever tool you’d like to determine the progress of your project. That is certainly a fine idea.
If you are working at a program level and deploying a particular replicated change to an environment with multiple sites, you need to be aware of when, who, what, and so on is happening there.
My project workbook lays out the tasks to be done where my tacker tells me where each site stands. One by one I go to cross them off as they get completed and I update with any sort of notes, concerns, follow-up items, and/or etc.
Should anyone ask me “Where are with ABC site?” or “Was there a change at ABC site?”, I can quickly respond or someone can just look it up in my tracker (log).
“What gets measured, gets managed.” – Peter Drucker
During a meeting I brought up the topic of performing a postmortem and then someone called me out on it saying that we should instead call it a retrospective because it is more of a neutral term whereas a postmortem has a negative connotation. They then pointed out we should see this as a positive situation as we can learn from our experiences.
My gut told me though that point was likely true, something was off about using the terms interchangeably . I just couldn’t put my finger on it at the time. I did know that a retrospective comes from the agile world whereas postmortem is more of a standard (waterfall) project management term.
As it has been bothering me for the past day or so, I decided to finally google the difference. The first hit brought me to this page which describes some variances. The key point is that a postmortem is an event that takes place after the project is done (post-death). As for a retrospective, it is an iterative event that occurs at the end of each sprint providing an opportunity for small improvements and/or shifts in the project before completion.
With that said, a retrospective is technically not interchangeable with postmortem because you could have retrospectives throughout the project. Once the project closes out, we could then hold a postmortem to review the overall project.
Yes, postmortem is still a morbid word but putting that point aside, the concept makes sense to refer to it as so. If you still feel uncomfortable with using this term, you could just reference to the closure review meeting as a project “lessons learned session” or “post-project review”.
Why not also consider then doing retrospectives throughout the life-cycle of the project before closure to collect insight and adjust course accordingly rather than waiting until the project closes out to hold such a session to review. Here is another interesting blog on why lessons-learned session can go wrong.
So this is your first time to roll this kind of project out? You put together a project plan together with your resources and identified everything you all need to get done. Great job.
Did you think about running the project plan with someone who has done this project before though?
Here is where you bounce your ideas and plans with someone who has done it before. He/She may have done this exact project or just maybe they have done something similar.
Wouldn’t it then be wise to sit down with this/these persons to make sure you collected all those lessons learned from their experience to help build into your project so you don’t have to stumble through preventable issues? Perhaps they have the project plan already built out, which you can review to adjust your own.
Take that 30 minutes to an 1 hour to pick their brain.
Your team is there to support you because we want to win together and make the organization stronger as a whole.
I’ll be honest. I haven’t used a project charter specifically or seen any in the companies of I have worked with. I have seen contracts and emails with requirements and high level of other information but nothing as solid as a project charter as defined by the PMBOK.
Is this a problem though? Clearly not. However, after thinking about not doing this and yet having this option available to me, I think it might be worthwhile. With a charter, I could determine this high level scope of work including target timelines and budgets along with who will be billed and who is the PM. Then I can hand this over to the PM knowing more clearly what they are assigned to and also give them a helping hand to get moving a bit quicker. This will also help me later down the road as it will eliminate any lack of clarity about what the project is, who is responsible, and so on.
I thought this site had a good run-down on how to layout a charter. They also published a template via google document, which is pretty helpful to get the ball rolling. Of course there are lots of other approaches and this is just one so have a gander to find what meets your needs.
I thought this study on skills was great as I came upon through a book I am reading to prepare for the PMI-ACP exam. This is the “Dreyfus Model of Skill Acquisition”. It helps to people into zones with their skill sets so you can better support them.
What I like about this is I have been trying to figure out where folks stand with their skill sets in regards to project management (PMBOK) and then building a training program based on where our weaknesses are and also have those who are at the top to provide the training. These definitions (below) give a pretty clear picture of what is required to achieving an expert level in a skill.
Once I break down everyone on the team in these categories against the PMBOK knowledge areas, I should have a pretty good sense on where we need to do better. Of course this is all subjective but at least it gives me a baseline of some sort, which can be tweaked overtime to be more accurate. Bringing everyone up to a near expert level could likely do wonders for the organization and for their own CVs.
The details of the novice to expert scale are broken down as follows:
You can also check out Wikipedia for more information on this subject.
Who wouldn’t want to stand up during a meeting and knock it out so they can go about their business? Seriously, this is a revolutionary idea that isn’t applied much in the business world. Are only the programmers and product mangers using this? I believe any team can apply this. Do you have to be using scrum to make use of this? I certainly don’t think so.
For instance during the execution of our work deploying infrastructure technology, the team gets together daily in the same room and we quickly run through the 3 questions,
- What did you do yesterday?
- What will you do today?
- What impediments are you facing?
I like to add on one more question though to find improvement for the future,
- What lessons did you learn yesterday?
This really helps the team get clear and be accountable for their work I find. It also helps me the PM to understand our progress so I can update dashboards and inform stakeholders.
The thing with the daily stand-up though is there needs to be some rules to make it effective. Once you have full buy-in from the team and it becomes a natural rhythm, it will work. At first, it is a bumpy course but you must remind the team of the rules and show the value.
Here is a really nifty graphic on high effectiveness and efficiency versus low effectiveness and efficiency from Version One Agile Management Blog. This really makes sense too me. Hope you find it worthwhile so you can add value to your organization.
One of the five principles for success from Rakuten is Speed!! Speed!! Speed!! According to their website, this principle means, “The Internet makes the window of opportunity for every small business. Accomplish in one month what it takes other companies a year to do, because we can only win by being many times faster than our competitors.”
I love that second sentence. Quick action with accuracy and quality certainly gives you a winning edge.
There is no reason why you should be pending information gathering to move forward. You are your own roadblock from getting the work done in this case. The PM should move swiftly in my opinion to have action items addressed and connect people to get the necessary information immediately.
Do not delay to set a schedule for your deliverable(s) either. Even if you are still pending information to determine a timeline, in my opinion, you should put down a tentative date anyway and drive hard to reach it. If you never schedule out the work, things will get dragged out easily.
Teams depend on the PM to drive the project so if the PM comes off nonchalant about getting things done, the team may not have the drive to move with speed and if the team moves faster than the PM, things may begin to bottleneck.
Don’t give yourself an excuse to push things out.
During meetings, people want to be done with it and back in the field doing the real work. As a result some folks are not present or prepared and then the value of the meeting diminishes. Could I have sent a mass email to everyone to address these issues and updates? Possibly.
If it is a large program with multiple PMs and stakeholders and we are not talking with each other regularly, then the project will likely go astray where we make similar mistakes that could have easily been prevented if they were present during the meeting.
We must prepare for meetings and bring forth risks, issues, and other challenges and updates on the program. As the program manager, I do my homework before the meeting to gather as much information as possible so we can bring these topics to the table and resolve them so everyone gets on the same page.
Agenda items are not to be rushed through either. If we highlight an issue and fix it, that doesn’t necessarily mean we resolved the root cause and have taken a lesson learned away. Here is where the PM stops and asks how could we have prevented this all together? This may take some time to resolve and it may not directly impact everyone right now but you should be present and provide your input.
We must be proactive in our work rather than reactive. We must constantly go looking for the risks and we must dig into the issues to find the root.
So please close your laptop and put your cell phone away and participate in the meeting. Take your own notes if that helps keep you focused.
Yes, I certainly think so. When you go on a trip, some folks prepare a checklist of the things they want to do and places to see. For some, they have a checklist of the things they need to prepare for the trip. For others, they don’t want to be confined and pressured to follow such a list. Each to their own you may say then.
How about when you go to a hospital then, should they freely do what they think is best? I would argue against this. Those who work at a hospital are running around handling multiple errands and well, there is a good chance they forget something or mix something up and that could be catastrophic for a patient. Atul Gawande wrote a book on checklists and it is well worth a read where he walks us through just this.
When it comes to project management, IMHO it is therefore worthwhile having a checklist. Perhaps better this should be called a task list with targets and assignees. This list provides us guidelines as to what, who, and when things need to be done for execution to ensure steps are followed properly based on team research, experience, and cross-functional impact.
To further add value in producing such a list is to review it when the project is done. Here we apply Kaizen to improve our process so the next person who runs a similar project is well prepared and more successful in executing. If it can be measured, it can be improved says Edward Demings and I couldn’t agree more.
Why then wouldn’t you want to have a checklist? Just why not?
I think I am notorious for doing this. I am sure people find it annoying that I repeat my questions even if rephrased them. I do this for a reason though. It is sort of like creating a password, they ask twice to enter it so to ensure that you are able to repeat what you inputted. If it doesn’t match, perhaps you need to make an adjustment.
I will rephrase my question just to see if I get a different response because if I do perhaps they heard me in a different way and they better understand or perhaps they didn’t quite get where I am going so that requires more discussion for better understanding. If their response doesn’t match it raises concern on my end as this person may only be beginning to think things through and starting to realize the efforts and requirements necessary.
If the person repeats back the same response (usually with a dumb struck face as they are wondering why I would ask again), I will then hold them to it. This also helps both of us to reinforce in memory actions required cause if we only hear/say it once, it is likely we will forget (that’s why we take notes, right?!)
Go on, annoy someone with your repetitive questions and see what happens.