Sprint Planning takes the form of a meeting involving the Product Owner, Scrum Team and Scrum Master. The Product Owner discusses the current Product Backlog, with a focus on the top-priority User Stories. The conversation involves the Product Owner’s explanation of the Stories, including the Acceptance Criteria and the Scrum Team seeking clarification so that they may make informed choices with respect to estimating and what they will commit for the Sprint.
Communications is, of course, the single biggest indicator of project success or failure. As project managers, we have to think about all aspects of communications, including how much, to whom, in what format, etc. We also get pretty savvy at knowing which communication channels to use.
A lot of project work gets done through informal, undocumented communication channels. This is not only OK, it’s actually necessary. Imagine if every conversation or information gathering effort we conducted required a documented plan. The fact is a lot of good data can be mined from the water cooler and coffee klatch gatherings.
There are two types of this informal network: the grapevine and the rumor mill. I would suggest that while both are informal, undocumented communication channels and that they may include many, if not most, of the same people, they are significantly different. The grapevine is an asset worth using; the rumor mill is something to avoid.
How are they different and what makes one an essential part of a project manager’s communication strategy and the other a liability? In my mind, it comes down to content and effect.
First, the nature of the content is qualitatively different between the two channels. On the grapevine, information is rooted in truth. It may not include the whole story, but the information available is fundamentally true. It is often a great source of information about prevailing attitudes, for example. A project manager might tap into the grapevine to find out how people are responding to an organizational change of some kind.
In addition, grapevine content is generally not specifically about individuals. The vine is more about ideas and things, and less about who did or said what.
Content on the rumor mill, on the other hand, is highly specious. Often the information obtained from the mill is patently false or so distorted by innuendo or editorializing as to be of little value. Of course, it’s not presented that way. In fact, you can usually tell if you’re tapping into the rumor mill by a qualifying comment such as “My brother’s roommate’s cousin heard….” The qualification serves the purpose of creating distance between the information and the person spreading it; it’s a way of deflecting ownership for the information.
Furthermore, the rumor mill is generally where you hear a lot more about specific individuals and a lot less about ideas. Name dropping on the rumor mill is rampant – and generally not a place where you want your name mentioned.
Still, it’s not always crystal clear as to which channel you are using based on content alone. Effect is also important to consider in order to distinguish between the vine and the mill.
The effect of the grapevine is positive (or at least not negative). Use of the vine results in shared perceptions, level setting, or improved understanding. The effect is not damaging or demeaning to others. When you are working the grapevine, you don’t feel uncomfortable about getting the information. Grapevine conversations don’t inspire ducking into empty conference rooms to avoid being seen. You come away from a grapevine conversation feeling like you could share what you learned with others without feeling like you violated a confidence or compromised anyone’s integrity. You are comfortable with your name being associated with grapevine information.
On the other hand, the effect of the rumor mill is generally negative. The purpose is really to provide cheap entertainment. It’s the “You’re not gonna believe what I heard” factor. When you are grinding on the rumor mill, you may look behind you or over your shoulder to see if anyone sees you. These are the conversations that make you want to find an empty conference room or somewhere to avoid being seen. Rather than about ideas or things, the rumor mill is almost always about people, and it’s generally not flattering. The effect is usually that someone is shamed or demeaned or at least presented in an unfavorable light.
The savvy project manager will always make good use of informal communications channels in developing relationships with stakeholders, getting buy-in, managing expectations, and keeping the project on track. The ethical project manager will also know which type of informal channel they’re using, when it makes sense to use it, and when it’s best to disengage.
Don't forget to leave your comments below.
Andrea Brockmeier is the Client Solutions Director for Project Management at Watermark Learning. Andrea is a PMP® as well as Certified ScrumMaster. She has 20+ years of experience in project management practice and training. She writes and teaches courses in project management, including PMP® certification, as well as influencing skills. She has long been involved with the PMI® chapter in Minnesota where she was a member of the certification team for over eight years. She has a master’s degree in cultural anthropology and is particularly interested in the impact of social media and new technologies on organizations and projects.
Every year there is a mad scramble by most companies to secure budgets internally for projects they intend to do for the following financial year. Typically, companies are flooded with requests from various departments to deliver capabilities and benefits through a variety of projects and programmes. However, companies are acutely aware that there has to be a balance between the long wish list of things to do, and the organization’s actual ability to deliver them. Usually this leads to an onerous quest to estimate the number of projects and programmes that can be delivered in a single year. In the absence of a workable corporate planning process (one that provides a prioritization framework to validate whether the right projects should be done or not) this becomes a daunting exercise for executives and their senior management teams. The purpose of this article is outline a number of techniques which on their own or collectively can assist companies to overcome this dilemma.
Establish a project filtration standard.
Given the chance, business units will add anything to the company’s list of things to do. Items that would never qualify as project work are often added. Once all the business units have finished contributing, the wish list is usually very long and lacks detail. Trawling through such a list and deciphering every item is a tedious exercise. Furthermore, to discover that a significant proportion of items do not constitute project work is extremely painful, and quite frankly a waste of the company’s time! To minimize the inclusion of non-project items and to encourage sufficient detail to reduce protracted dialogues with the business units demands a project filtration standard to be established and communicated to the relevant parties. At its simplest level, this could entail distinguishing between development work and operational work. In practice however, a more versatile standard is required to perform the filtration. This should consist of: a business case for the intended project work, its alignment with the corporate’s strategic objectives, project size (small, medium, and large) and high-level project information (sponsorship, scope, objectives, time lines etc.). If the filtration standard is implemented correctly, it should preclude items like “photocopier installation, exchange server memory upgrade, 10 employee desks” from appearing on the list. Additionally, short sentences to describe project work such as “ERP system is required because everyone else has one, and it will take 6 months to implement” will be actively discouraged and excluded from the list, unless sufficient detail is provided.
How much money is available to spend on projects?
Another technique that can be employed to restrain the company’s wish list is to impose an overall project budget for the company. The total budget can be divided into specific budgetary envelopes which the business units use to calculate project submissions. However, the value of the total project work submitted must not exceed the overall project budget, but individual envelopes can be exceeded. In practice, this requires strict rules to regulate negotiations between the various business units; otherwise there is a danger that whole exercise can become protracted.
A variation to this approach is to set a specific monetary threshold to admit project work into the company’s to do list. Therefore, if an item meets the threshold value, it is included on the list. Nonetheless, an overall cap on project spending is imposed to inhibit too many items from entering the list. Whilst both approaches are quick and dirty, they lack the intelligence to ascertain what really constitutes project work.
Use historical data to determine organization’s capability to deliver.
The two techniques described so far, are good at restricting the company’s wish list, but are quite poor at providing an indication as to how many projects the company can actually deliver. One technique that can help in this respect is to use historical project data to determine the organization’s current ability to deliver number of projects. The accuracy of this method is greatly dependent upon the quality of the project data: if the project data is incomplete, inconsistent, or contradictory, then it may be prudent to use procurement data to calculate just how many projects started, or stopped, in a given a year. However, even this may not be enough to provide an answer with certainty. If the quality of project data is too poor to provide a reliable figure, then benchmarking could be used to determine company’s delivery capability. However, benchmarking provides the industry figure as to what a similar size organization in a specific business area should be delivering. It is not a measure of how many projects the organization in question can deliver presently. In any case, both historical data and benchmarking can assist organizations to aim for the optimum number of projects they should deliver in a given year.
Use critical resource head count to estimate the number of projects.
An expedient method for fixing the number of projects is to base it on the number of critical resources used by the company to deliver project work. The critical resources can be project managers, analysts, architects, designers, testers, trainers etc. All organizations have a finite number of resources and in the current economic climate; the tendency is to do more with less. Hence, resource sharing is imperative to deliver projects. So it should be quite straightforward to come up with a reasonable figure, which all parties can concur with. For instance, if there are fifteen project managers then it is reasonable to assume that they would not be able to deliver more than twenty medium size projects.
One of the ways to do more with less is to group projects into programmes and then manage the delivery to produce the requisite capabilities and benefits. The advantage of this approach is that the organization as a whole can focus on a small number of programmes in a given year. However, the greatest challenge facing such an approach is the organization’s maturity to plan and effectively collaborate. Provisions are also made for unplanned projects, or programmes, which can arise due to market conditions and regulatory edicts.
Executive threshold to sponsor projects and programmes.
Lastly, one of the biggest constraining factors is how much time executives can devote to project sponsorship. Typically, executives have their schedules full with strategic, operational, management, financial and commercial responsibilities. Finding time to sponsor projects in additions to these responsibilities is a struggle for the best of executives. Most likely, executives will not be able to commit beyond one or two major projects and programmes. Therefore, using executive attention to measure the organization’s ability to deliver is an extremely useful technique.
In conclusion, a selection of any techniques listed above can be employed to calculate the organization’s ability to deliver within a defined budget. However, this is merely a temporary solution. A more permanent solution necessitates such techniques to be integrated into the company’s corporate planning process. Only then, will the company be able to accurately determine its capability to deliver a specific number of projects and programmes each year.
Don't forget to leave your comments below.
Abid Mustafa is a seasoned professional with 18 years' experience in the IT and Telecommunications industry, specializing in enhancing corporate performance through the establishment and operation of executive PMOs and delivering tangible benefits through the management of complex transformation programs and projects. Currently, he is working as a director of corporate programs for a leading telecoms operator in the MENA region.
Ask virtually any person inside your organization what the value of product management is and you’re likely to get a series of different answers or even quizzical looks. This is ironic, because product management is critical to company success. Although no one inside the organization wants to eliminate product management, few people can succinctly describe its value to the organization.
This begs the question, why is it so difficult for people to understand and communicate product management’s value?
The main contributor to this confusion can be traced to the lack of a body of knowledge to lay the cornerstone of the profession. Without industry-wide clarity on the profession’s core language, process groups, and knowledge areas, it’s easy to understand why product managers and extended team members struggle to describe product management’s core value proposition.
Another part of the problem is the way the product-management profession chooses to illustrate the value of the function. The traditional — and commonly accepted — view of product management typically places the product-management function at the center of a daisy wheel, the hub. Radiating from the hub is a series of circles. Each circle represents a different function — sales, marketing, and operations, to name a few. The product-management hub is connected to the spokes by a series of double-sided arrows. These arrows represent two-way communication between product management and the other company functions.
Source: Take Charge Product Management© by Greg Geracie. All rights reserved.
The hub and spoke model highlights two distinct but interconnected aspects of product management. The first is product management’s primary function to ensure appropriate levels of communication between the various functional spokes, illustrated by the arrows in the diagram. The second aspect highlighted by this model is product management’s active work coordinating all of a company’s various functions in pursuit of their product objectives. This is illustrated by the neat arrangement of the surrounding circles.
The implied value proposition of this model is its emphasis on product management’s role in ensuring functional alignment and effective communication in pursuit of a company’s product goals. No one would argue that functional alignment and coordinated communication is important to the success of a product-management organization, but this model only marginally touches on product management’s true value to the organization.
The true value of product management — and what makes it so critical to company success — is the function’s unique focus on creating and sustaining value throughout the entire product life cycle. This role in the organization clearly differentiates product management from all other functions. For instance, project managers focus on successfully managing projects to completion across one or more stages of a product’s evolution throughout the life cycle. Business analysts are actively engaged in the upfront analysis of business problems, requirements gathering, and documentation. Only the product-management organization is responsible for optimizing product performance throughout the entire life cycle of a product — from conception to retirement.
Perhaps a better way to think about product management and its critical role in ensuring organizational success is to envision three pillars. These three pillars make up the entirety of the organization. The first pillar is Operations. The operational pillar encompasses the executive leadership team, shared services such as finance and human resources, and the remaining staff who spend most of their time ensuring that the organization runs smoothly. This operational group generally makes up the smallest percentage of the organization’s total head count.
The second pillar is the Value Creation Team. This pillar includes all the individuals in the organization who contribute to creating and sustaining value. This is achieved by producing new products, enhancing existing ones, or simply supporting the value that has already been created.
Depending on the size of the organization, a value creation team will be led by one or more product manager that are held accountable for achieving the company’s product objectives. Although product managers are responsible for achieving results, no product manager can do it alone. Effective product managers work closely with cross-functional product team members from across the organization. These include project managers, business analysts, engineers, quality assurance staff, research and development personnel, and customer support workers. The Value Creation Team pillar usually makes up the largest percentage of employees on a head-count basis.
The third pillar is the Revenue Capture Team. This team includes most of the marketing organization that supports the activities of the sales organization. These activities include lead generation, collateral development, and outbound marketing programs. The Revenue Capture Team also includes the entire sales organization, whose mission is to capture the revenue contractually that results from the value of the products.
When viewed from the perspective of the three pillars, product management’s value becomes clear. The product management organization acts as the focal point for value creating and sustaining activities.
Communication and alignment are important to product management’s success, but they’re secondary to product management’s real mission — creating and sustaining value throughout the entire product life cycle. This role fully differentiates product management from all the other business functions and demonstrates why product management is so critical to company success.
Don't forget to leave your comments below.
Greg Geracie is the President of Actuation Consulting, a world-class provider of product management training courses and advisory services to some of the nation’s most well known organizations. Greg is also the author of the global best seller Take Charge Product Management© and the Editor-in-Chief of The Product Management and Marketing Body of Knowledge©.
My son’s hockey team won a tournament recently that included a series of hard-fought, well-earned victories. As the athletes came into the lobby from the locker room, everyone cheered, recognizing each individual contribution. Another mom made a comment out loud that many of us hockey parents think just about every time we see them come out of the locker room: “They’re so little!”
It’s truly amazing to see 9-year-olds play hockey at the level that this team plays. They skate on the ice as though they’re dancing on pavement. They handle a stick with astounding skill. They move the puck up and down the ice with agility that sometimes takes my breath away.
The definition of done is a fairly popular (and sometimes emotional) topic in the Agileverse. It seems everyone has an opinion on the matter ranging from “It depends,” to “Let the teams decide,” to a meticulously designed set of business rules and criteria that account for every possible scenario. However, as organizations adopt Agile practices (and specifically, Scrum), they seek to leverage guidance from those of us who have already blazed the trail. Why then is this such a complex topic?
One aspect is that the word “done” is overused. We must distinguish between different contexts of "done." There is "done" at the story level, epic level, release level, product level, etc. Each of those meanings of "done" has different criteria. For the purposes of this article, we are only going to look at the done criteria for a user story.
Another aspect of the problem with done is perspective. The word "done" is often used to mean "complete," as in a Scrum team saying, “We are DONE with this story." It's also used to indicate acceptance, as in a product owner saying, "This story is done." I typically teach and coach it this way: Don't say “done.” Instead, use “complete” and “accepted” for more specific indications of status. This gives way to defining completion criteria and acceptance criteria (Figure 1).
Click to expand image.
Figure 1. Done Criteria = Completion Criteria + Acceptance Criteria
The criteria for completion are summarized as follows:
- “Code complete” – as defined by the organization/teams
- “Unit tested” – as defined by the organization/teams
- “Peer reviewed” – as defined by the organization/teams
- “QA complete” – as defined by the organization/teams
- Documented (as needed; determined by the Scrum team through tasking at the beginning of sprint)
The Scrum team determines when the completion criteria have been met with the guidance of the Scrum master. At that point, the story is considered “complete.”
The criteria for acceptance are summarized as follows:
- The list of expectations for a specific user story as defined by the product owner prior to the beginning of a sprint.
- The product owner may define these alone or with the help of the Scrum team and/or Scrum master.
- For cases where acceptance criteria are not clear, a spike user story will be used to define the problem and acceptance criteria for a user story to be completed in a future sprint.
- The Scrum team must agree to these acceptance criteria at the sprint planning meeting.
- Minor changes to the acceptance criteria once the sprint is underway are acceptable as long as there is formal agreement between the Scrum team, Scrum master, and product owner
- When the Scrum team believes these acceptance criteria have been met, the user story is ready for a product owner review (demo), which occurs throughout the sprint
- The review (Demo) of each user story should NOT be left until the very end of the sprint
The product owner determines when these acceptance criteria have been met. At that point, the user story is considered “accepted.”
This approach provides a framework that is modular and can be adaptable around the definitions of “code complete,” etc. but clearly delineates the roles and responsibilities associated with delivering and finalizing work. If a particular organization is striving toward 100% automation of functional tests that become part of a holistic regression test suite, then “creating automated test scripts” would be expressed in the QA complete criteria.
Further, one group might agree on what “peer reviewed” means but not the “QA complete” criteria. Using this modular definition, each group can customize these definitions to suit their team’s specifications.
As part of this exercise of defining “done,” I have also identified in the following diagram (Figure 2) the different stages at which events occur in terms of the definition of done:
Click to expand image.
Figure 2. Definition of Done Process Mapping
The first column defines the event or phase during which the activity in the second column takes place. Column three shows who is responsible for the action item in column 2. In one of the teams I am coaching, there was a highly contentious relationship between the product owner and Scrum team, and this diagram helped sort through who was responsible for what and when. This, along with a well-defined definition of “done,” set expectations and the conflict was neutralized.
Each organization (and team) must come to a consensus on what the definition of done is for their particular projects/products at various levels (story, sprint, release, etc.) In the next installment of this series, I will explore what the definition of done is at the sprint level.
Don't forget to leave your comments below.
Daniel James Gullo, PMP. CSP, CSM of Trinacria Consulting is a proven leader in the field of Information Technology and Information Systems who advocates and evangelizes best practices and quality for projects in all areas of business. Specializes in delivering software development and testing projects which are on-time, under-budget, and high-value. A professional with demonstrated success in Agile and traditional project / program management, business analysis, quality assurance, and consulting services. A highly praised and recommended consultant with an extensive history of satisfied customers and clients. Fiscally minded with both local and global experience. Open to travel both domestically and internationally. Effectively manages teams and resources around the globe both on-site and remotely.
Project managers have the immense task of juggling requirements and resources that are often not under their direct control in order to produce the required project deliverables within the limited constraints to which they must adhere (scope, time, quality, etc.). Even if the perfect project plan could be designed and executed, it would not remove all of the risks that could ultimately impact a project. Plans must inevitably change for one reason or another.
Successful project management abides by several principles. Essentially, every project needs three components to be successful: it must come in on time, within budget, and to the degree of quality that is expected. Sounds easy enough, but every experienced project manager knows that anyone who counts their proverbial chickens before they hatch will not complete the project on time, budget, or with quality.
Successful project management has tended to rely on time-tested and proven methods of planning, managing, and charting workflow throughout the project cycle. The old saying, “When it’s not broken, why fix it?” can certainly be applied here; however, what if a new way of managing the workflow in a project cycle was more efficient, more accessible and more transparent to all members of the team?
Each year, as project managers we take courses and read articles and books on how to improve our project management skills: how to track the critical path, influence without authority, tackle bigger scope and bigger budgets, work with remote teams, flush out the ‘right’ requirements, engage the teams we’ll need for success and many other topics. Often, these are great courses and articles with great tips and advice that we use every day to deliver projects assigned to us. One area where PMs aren’t always included—or do not involve themselves in—is the project selection process, that pre-initiation stage where the project is still a concept, someone’s brainstorm or someone’s personal pet project.
Part II: The Solution and Its Value
Viewing Cyber Security as a Business Solution
As a continuation of Part I, although advancements in technology have enabled organizational strategies they came with a price to pay given the rise in cyber breaches. Cyber security continues to be a moving target with no final technological solution insight. Considering the rate of progress in new technologies and their social prevalence, solutions are now more dependent on a person’s mindset, critical thinking abilities, and an increase in individual responsibility. These facts lead us to believe that the most effective resistance against cyber threats must now be built on shifting an individual’s mindset, adjusting human behavior and evolving legacy methodologies. Cyber security has elevated to become a required attribute for successful organizations and career professionals going forward. Cyber safe practices require a proactive approach in addressing a new generation of cyber breach challenges associated with strategic asset delivery and survivability. The first step project managers should take is to make cyber security a priority and position cyber safe practices as part of the solution in the upfront initiation and planning processes. Project managers and delivery team professionals such as business analysts should also incorporate cyber security practices into the remaining project phases to ensure traceability of established cyber security requirements.