Articles (508)
0
Stop Promising Miracles: Wideband Delphi Team Estimation, Part 3
Written by Karl Wiegers
The first two articles in this three-part series, adapted from my book Practical Project Initiation: A Handbook with Tools, described the first four steps in the group estimation technique called Wideband Delphi (see Figure 1). This article, completes the description of Wideband Delphi by describing the final steps in the process.
Assembling Tasks
The Delphi session isn’t finished when the estimation meeting concludes. Either the moderator or the project manager assembles the project tasks and their individual estimates into a single master task list. This person also merges the individual lists of assumptions, quality- and process-related activities, and waiting times.
Project Benefit Validation Brings Rigor and Credibility to Process Improvement Initiatives Part 1
Written by Julie BrignacBusiness Challenge
Business Improvement initiatives are getting a lot of press these days:
“…our projects saved over $10M in the first 12 months of deployment using BPM”.
Thus, it seems logical for an organization to jump onto the process improvement bandwagon. Much is promised of business improvement efforts, and there are many capable consultants and companies willing to support a company’s BPM deployment that can last months to years. But how does an organization know that the business improvement efforts will really result in a quantifiable benefit to the business? Process improvement initiatives are not inexpensive to start or sustain over many years, and most executives require the clear identification of benefits to justify the expenditure of training resources and driving project work before approving a long-term initiative.
The Evolution of Project Management and Scrum: Scrum2
Written by Chris MerrymanThe next step in Scrum’s evolution is long overdue. Almost everyone who has spent a few years in the software development world has been exposed to a taste of Scrum. Each organization has their own twist on its implementation, but without a doubt, Scrum is the most recognized and utilized Agile methodology available today. But with Scrum’s use we all hear about its limitations and why it doesn’t work. For instance, “How can I secure people and capital with the lack of planning that Scrum encourages?”, “Scrum won’t work for my distributed model”, “Scrum is too unstructured, we need a reliable approach”, and unfortunately, “unstructured” is one of the more mild words I’ve heard on the topic. The list of limitations goes on. And likewise, in the project management world we hear similar sentiments. The latest Project Management Institute (PMI) Certification (PMI-ACP) is a good step in the right direction but doesn’t bring the two methodologies completely in sync. Being from a project management background and also being a Scrum Master for several teams utilizing the Scrum process, I can attest to some of the shortcomings of both methods; however, combining the two methods could be the evolutionary change that the software development community and their sponsors/stakeholders have been looking for.
When is the last time you went to a project or sprint retrospective and you walked away feeling like something was accomplished? Effective retrospectives are an anomaly, and we rarely walk away feeling like anything is going to improve.
In my experience poor retrospectives are due to two reasons:
- Attendees need time to warm up and only get to the heart of the issues as time runs out on the retrospective meeting.
- We have too many things to improve, so we don’t improve anything.
You can address these key issues with seven simple steps.
Step 1: Pre-Survey
Since it takes time for a team to warm-up during a retrospective, you can turn the burners on a little early by having the team complete a survey before they come to the retrospective. I suggest doing this within two days of the actual retrospective meeting. This will help the team remember the project issues before they come into the meeting, and start productive conversations earlier.
What makes a successful PMO? A great deal of hard work? Definitely. But there are some other ingredients in that “special sauce” that enables a PMO to succeed. Let’s explore.
A few years ago Jack Welsh of GE fame lead a keynote speech on large programs. He was presenting to the business leaders of some of the largest enterprises in the world. The speech began something like this:
“If you can’t get top management to support your program, don’t even bother. Don’t even waste your time.”
Why did Jack say that? Because to him, adoption is so important that a program is doomed to fail without it – all the way from the top to the bottom. You can spend an extraordinary amount of time, effort and financial resources around setting up a program, developing a methodology and implementing a solution but without the team being ‘on board’ with your program you will have a very difficult time succeeding.
Virtual Meeting Challenges: Stop Fighting the Multitaskers
Written by Andrea BrockmeierDuring the Q and A following my recent webinar, Offsite and On Board, most questions pertained to challenges around people multitasking during conference calls and online meetings. Evidence of people multitasking during virtual meetings includes the tap-tap-tap of keyboarding, silence when asking for input from someone, and the steady drip of “Could you repeat that please?” from attendees.
I have good news and bad news to consider before exploring possible strategies for dealing with the multitaskers.
First, the good news: Those of you who struggle with virtual team members multitasking during conference calls and online meetings can stop worrying about it because… they aren’t.
That’s right. There is no multitasking going on in any of our brains. We simply are not wired to do it. There is ample research to prove this, yet we continue to delude ourselves into thinking we can intellectually process two things at once.
There are, however, two things we can do that make us think we are multitasking:
Project Nightmares - Gordon Ramsay to the Rescue!
Written by Bill Dow, PMP
I am a huge Gordon Ramsay fan; from Kitchen Nightmares, to Hell's Kitchen, across-the-board Ramsay is both an entertainer and expert in his field. The magic he works turning around restaurants is amazing. If you spend any time watching Ramsay, and actually listening to him – which people forget to do – he clearly knows what he is talking about in the restaurant business. He has success around the world, is a proven leader, and people should be honored to work with him.
Recently, I was watching an episode of FOX's Kitchen Nightmares,(Mauk, Hayden T.,(Senior Producer), Raigel, Scott (Producer),(2013) Kitchen Nightmares [Television Series] and I started thinking about what Ramsay does when he evaluates restaurants. Many of those same processes could easily be modified to the project management industry regarding the way we evaluate our projects. If you are not familiar with the show, let me walk you through how he turns around restaurants.
Stop Promising Miracles: Wideband Delphi Team Estimation, Part 2
Written by Karl WiegersIn the first article in this three-part series I described some of the reasons why estimates often deviate wildly from reality, and I introduced an effective technique for group estimation called Wideband Delphi (see Figure 1). This article continues the description of Wideband Delphi, showing how the individual preparation and estimation meeting steps are carried out.
Individual Preparation
Let’s assume you wish to estimate the total amount of work effort (typically expressed in labor hours) needed to complete a certain project. The estimation process begins with each participant independently developing an initial list of the tasks that will have to be completed, using a form like that in Figure 2. Figure 2 illustrates a very small estimation activity, developing the requirements for a new project cleverly titled Project X. The person who completed this form initially identified five tasks that would be involved in developing requirements, the first five items listed under the “Task” column heading.
GEM: The Most Crucial Factors for Project Success
Written by Chi-Pong WongThree crucial factors for project success
Successful projects are built upon many factors. Among them, three are most crucial. They are like the pillars of a solid foundation upon which building successful projects becomes possible. Missing these three vital factors, project success would be any project manager’s pie in the sky.
GEM is the foundation built by the three most vital success factors
Having all success factors working in harmony for any project is not practical, if not impossible, and project managers typically have to cope with what they don’t have when striving for successes. To conquer project perils like technical illiteracy, unsuspected risks, scope creeps, ineffective tools, contentious stakeholder collaborations, over budget, under resource or bloated schedules, project managers must have three most crucial success factors on their side. Missing any one of these three will very likely cause the projects to fail. These three vital factors are the pillars to hold up the foundations upon which building successful projects becomes possible. This foundation is named GEM, which is the acronym of the first letters of the three pillars, which are:
Use Sociocracy to Scale Agile Organizationally
Written by Derwyn HarrisWe are at an important juncture in the evolution of product delivery. Agile methodologies have lost sight of some of the core values, and not enough people are using social technology to fully realize Agile’s potential.
Agile, once hailed as the answer to development woes, has become a source of contention and debate. Organizations with larger, more complex projects struggle to adopt Agile. Some organizations won’t even try due to formal processes designed to ensure the projects meet regulations, follow contracts and avoid costly mistakes. This is especially true in industries where the final product includes hardware that can’t easily be built iteratively.
Despite these concerns, isolated teams within organizations continue to implement Agile where possible. This inevitably is worse because it creates a disconnect between the teams operating within Agile and the rest of the organization.