PM Tailoring

The Project Management Body of Knowledge (PMBOK) presents the guidelines for best practices that can be applied to projects. It also presents a standardised terminology. PMBOK guideline preparation itself follows ANSI standards, so it is natural that it goes for a standardised terminology! Generally a single word (or phrase) is used to define or describe a process (or element) of project management. Those who have worked on projects can readily appreciate the benefits of standardised terminology in the project management profession. In the real world, we have seen the confusion created by using different words for the same thing.

PM Process Mapping

One of the important phrases that have started appearing from PMBOK Guide Third Edition is tailoring. The usage of this term in the later editions is growing, and there is an even greater emphasis on tailoring in the 6th edition, which emphasises the importance given to tailoring. Project management methodologies/processes are constantly increasing; and real-life projects are becoming ever more diverse and complex! The saying One size does not fit all goes well here. It makes sense now to throw some light on tailoring.

Tailoring is making project methodology fit. There may be different situations warranting different methodologies and the adaptation of different processes. Industry type, environment, organisational experience, kind of project, etc., may lead to different processes being chosen for different projects. Each project is unique with its own set of goals, resources and constraints. Tailoring is the act of adapting different processes to make them suitable for different projects. The standards, guidelines and rules presented in PMBOK may be general and globally applicable. There is a need to design and tailor the processes so that desired goal is achieved in each project.

The project manager along with his/her team is responsible for the process of tailoring. To quote PMBOK,

for any given project, the project manager, in collaboration with the project team, is always responsible for determining which processes are appropriate, and the appropriate degree of rigor for each process. Project managers and their teams should carefully address each process and its constituent inputs and outputs.

When the project manager and his/her team do this they obviously buy into this.

There can be several stages in tailoring. In the initial stage, the PM methodology may be based on the PMBOK Guide. In the second stage it is more geared towards the elements of the project and based on Organisational Project Management Office (PMO) guidance. The third stage of the tailoring can be at the project execution level, depending on how well suited the processes are for achieving the desired outcome. As we can see, tailoring is done throughout the entire life cycle of the project. Another important aspect to remember is the documentation. There is a need to document the tailoring process approach in the project management plan, and then at the execution stage, in terms of how each process was tailored, and why it was added, removed, or revised.

Four key takeaways from this blog post are:

  1. Tailoring is making project methodology fit.
  2. The PM and team are responsible for the tailoring process.
  3. Tailoring is done in three stages.
  4. Tailoring needs to be documented.

Join the conversation and follow us to get an update on PMP exam preparation or take an open PMP test.

A user story is a short and simple description of the customer’s need. It is usually told from the perspective of those who are requesting the new feature or requirement. A user story is short and sweet, but prompts the developer to get a handle on what is required. It makes it easier for the developer to produce an on-target feature of superior quality, and allows them to understand the goals and needs of the customer more quickly. It is normal to write a user story on Post-its or index cards.

Usually, user stories have a specific format, such as the following:

“As a [persona],
I want to [do something],
so that I can [realise a reward].”

Product Owner Requirements

 

This is a sample from my training course where we ask students to use Lego to build features.

The user story prompts the user to ask questions, and suggests, for instance, specifying not just any cow, but a cow that can be milked.

 

 

Using lego to plan creation of stories

Use the acronym INVEST to get to the best user stories.

So a user story should be all of the following:

  • Independent (I): A user story should not depend on another one. Dependent user stories are difficult to estimate and prioritise, and removing a dependent user story often causes problems in others.
  • Negotiable (N): A user story is not just a text detailing the features that the product owner expects, or a piece of functionality that will be implemented. Look on a user story as a starting point for a conversation, or an opening problem for the team to suggest solutions to.
  • Valuable (V): We cannot just create fun user stories. We must describe the value that the customer will get from this user story.
  • Estimable (E): There must be enough information to allow the team to make an estimate about the user story, otherwise it cannot be started.
  • Small (S): A user story cannot take more than one sprint to complete. Any user story larger than this will be impossible to plan or estimate safely. If it’s too big, create an epic and split it into smaller user stories.
  • Testable (T): If you cannot test a user story, you cannot know whether it’s worked. If a specific user story cannot be tested for lack of information, do not put it in your backlog.

Use themes and epics when necessary.

If you use the INVEST concept to create user stories, and can keep to it, you’ll have good quality stories. In some situations you will see the need to separate them into themes or epics.

  • Themes: A theme is a group of user stories that share attributes in common. Often, multiple user stories will have similar goals, or be related in an obvious way. All of them are directed together to a single path; however, they do not need to encapsulate a specific feature or necessarily be delivered together. So a theme may contain several epics or several user stories.
  • Epics: An epic is a great user story that cannot be completed in a single sprint, resembling a theme being built with multiple stories. Although the stories that make up an epic are completed independently, their value to the business may not be delivered until the entire epic is complete. This means that it does not make sense to deliver an epic until all the stories tied to it are complete.

Althris provide Scrum Master Training in Dublin and Cork, check out our PSM sample exam papers.

Sprint Retrospective is the opportunity for the entire Agile Team (Product Owner, Scrum Master and Development Team) to inspect and create an action plan for improvements to the next sprint. The meeting helps the entire team to identify what worked well, and what should be improved.

I have some tips for making sure the meetings go swimmingly:

  1. The Scrum Master must be well prepared as a facilitator for the meeting.

There are thousands of retrospective techniques published in books and blogs, which when applied well achieve wonderful results. The main question is how and when to apply one particular technique or flow rather than another. However, an important issue is not only knowing the technique but knowing how to facilitate a retrospective.

Expertise in conducting good retrospectives is only gained after a period of experience. There is no single way for the Scrum Master to conduct good retrospective meetings.

The points below will help the Scrum Master to be prepared for the meeting:

  • Be prepared: Collecting relevant facts prior to the sprint cuts out the discussion as to whether, say, we have 20 or 25 stories completed.
  • Let all participants express their points of view.
  • The more the Scrum Master knows the team and the people, the more efficiently he or she can conduct the meeting. Get to know you team mates, and help them express themselves.
  1. Choose a good time for the meeting.

The scheduled day and time of a Sprint Retrospective is very important, because depending on the team and the daily work scenario, people may be tired, or focused on other important aspects such as deployment or bug fixes. You have to make sure everyone is available. First thing on the day after the sprint finishes sound good, but team members may also need time to gather their thoughts.

  1. The product owner needs to be present.

It is critical that the product owner is present to make a meeting effective and more productive. This is even written in the Scrum Guide. The first sentence of the Scrum Guide on Sprint Retrospective is as follows: “The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create an improvement plan to be implemented in the next Sprint.”

Since the Scrum Team is composed of the three Scrum roles, including the product owner him/herself. The presence of the product owner is mandatory, whether or not your Scrum Team enjoys it.

  1. Do not look for the guilty.

One of the biggest fears when people enter a Sprint Retrospective is that the meeting becomes a witch hunt, where the only thing that matters is to find whoever is guilty for the problems. To avoid this, it is very important that the team understand the objectiveness of the meeting. The team should be prepared from the outset to listen to constructive criticisms so that they can create an action plan of improvements for the next sprints.

This will only be achieved after a time of maturation of the team within the Agile methodology, so these discussions should be encouraged by the Scrum Master.

The 7 Key Roles of the Executive Sponsor in Modern Project Management

Perhaps the most crucial roles in any project is the Executive Sponsor role. Often underestimated, weak project sponsorship leads towards a dramatic increase in failure rates, a waste of budget and prolonged deadlines.

All these pitfalls can be prevented with strong sponsorship, a sponsor that has some ‘skin in the game’ and can act as a conduit to the organization as a whole.

This article will show you the importance of efficient project sponsorship and point out the 5 key roles of the sponsor in the complex environment of international projects.

The Increased Complexity of Project Management

Project Management has become more complex. Over the past decades an increase in global connectivity, the demands of flexible business models and the assimilation of markets has led to more transformational projects. Project must now have an even greater business focus and business benefit.

 

 How does the Executive Sponsor fit into this framework?

The executive sponsor is the go-between the organization and the project management team. This position is a tightrope act between inefficient micromanagement on the one hand and too little involvement on the other hand.

Especially since the project’s benefits, results and potential shortcomings fall in his area of accountability, the executive sponsor must find the right balance between his need to control the outcome and his team’s need for self-determination and –management. He is the CEO of this temporary organisation.

 

Concerning the project, a successful sponsor therefore should:

#1: Be accountable for the project, responsibility may be delegated but the executive is ultimately accountable, he is the chairman of the board of this temporary organization (the project) 

#2 Guiding the Project Vision: The sponsor is the spokesman of the project. They own the business case and should be constantly vigilant that the project is set to achieve it.

#3 Unified Direction: The executive’s job is to motivate, gain commitment and communicate with other stakeholders and ensure that decision made are not undermined. The project manager has his delegated authority 

#4: Mentor the Project Manager: The sponsor holds close contact to the project manager and offers guidance and coaching while avoiding being overly controlling

#5: Control Project through appropriate governance : The sponsor is keep informed of the project progress against a plan. A project charter and/or Project initiation document should set tolerances and expectation on the level and frequency of reporting

#6: Make Decisions: Sometimes there have to be changes to the original project plan. The sponsor decisiveness support a fast turnaround in the project.

#7: Organize Resources: The sponsor makes sure that the project’s aims are fully realized by efficiently organizing the available resources. The is done by enabling cross functional integration and the commitment of resources

The Executive Sponsor: A Key Factor to Your Success?

Having the right sponsor in place is the only way to achieve significant results. They strive to keep a focus on the organization benefits of the project outcomes which support good decision making in the project.

How is your current project structured? Do you have a sponsor in place and do you see his or her benefits? Effective sponsorship is a key factor to your project’s success.

PRINCE2® has a detailed definition of the roles of the executive sponsor (Executive) supporting senior roles. Even if you are not using the PRINCE2 ® methodology there is still plenty to be learned from the roles defined within the methodology.

Our world is built up of plans and estimate, business judge the CEO’s and senior manager by the estimates they produce and how they deliver on them. Without estimate we can’t prepare for the future.

In our daily life we plan using estimates, like how long will it take us to get to the airport, how much will we need to put aside for our summer holidays (vacations?)

The process of doing estimates has significant influences on our decisions making. For example can we afford our trip to France, or how long do we leave for the airport before the flight. Failure to make accurate estimates could have a lasting impact. We could miss the flight, or we could overspend on the holiday resulting credit problems.

Clearly for big business and for smaller personal decision estimation is vital. It is no less vital for our development or business change project to have a handle on the costs and delivery timescales. But is estimation the way to do.

Business stakeholder need to incorporate the estimates into their cost and deliverables. They need to be bought into the estimate in order to buy into the project. When an estimate is asked for, it’s critical to understand why an estimate is needed.

In scrum we estimate in detail, scrutinise, reviewed and update these estimates regularity. But the purpose and timings of these estimates is not what the business stakeholders is looking for.

Business stakeholders want to have some idea of when they’ll get which features, the number of resources needed to meet a timeline, and of course costs. None of this information can be provided without taking time to do some estimation and planning.

To get to a satisfactory solution to the conflicting requirements we need to separate out the stakeholders requirements into the 3 elements and deal with them separately.

1 Planning –

Planning gives the business an idea of the resources timescales and activities. The act of planning is a large part of the value, not the piece of paper the plan is written on. This plan is not about specific component delivery but about how we deliver the cycles and more importantly it is to come to a shared understanding of what we as a team can achieve.

2 Budget –

Budgeting projects uses a top down approach, where you decompose only so far as you need to in order to have enough information to make your decision.

Budgeting can be done in much less time and Budgets make better sense “what can you do for €XX.xx” This approach clears the way for the product owner to set some of the priorities.

Secondly Knowing the customer’s or management budget expectation impacted the developers’ estimates. It’s called anchoring.

3) Agile Estimates –

It is easier to have confidence that we can accomplish small things than big things regardless of what number we attach to that smallness/bigness. Agile estimates are small, lower level and feed into the budget and cycles that we have set out.

We are close to the action and have more confidence that we can deliver the controlled delivery. Smaller results in less variations and the variation in estimates easily to manage. The delivery teams can then stand over their estimates.

Agilists must accept the need for revenue and budget forecasts to be taken seriously

It is easy to join the chorus of opinion that software project estimation is waste and must be eliminated. Whilst I can understand the objections to spending valuable time preparing and rationalizing a set of estimates for ill-defined features or projects.

Breaking it into the 3 process can satisfy bot the business and the agilest

Inside every project manager is an ‘agilist’, trying to get out. In fact, that’s true of everyone in a project team. While the status quo and comfort zones have an undeniable attraction for our lazy streaks, we’re not made to do the same things over and over again. We may be apprehensive about change, but we also need it. The perils of endless repetition include boredom and rapidly increasing error rates. So what’s the answer?

A little root cause analysis will help here. Change is stressful when it involves the unknown. We worry about whether we’ll feel good about what comes after, compared to what we had before. When constant change is a fundamental part of an agile project approach, it can turn into a real tug of war between the urge for variety and the fear of failure or degradation of a situation. The pressures of project sponsors and end-customers for delivery of new products or services then exacerbate the problem.

But good methods for managing change and succeeding with agile methodologies can be learned. Agile project management may be characterized by fast-moving activities focused on action for rapid results. Yet it still relies on well-defined concepts and techniques to work successfully. It can be taught, internalized and then applied with confidence – and therefore without stress or worry – about the quality of the output of each agile cycle. Going agile and embracing change can then become a source of satisfaction for all concerned.

 

“Just say No.” How many times have we heard that advice? In some situations, it may be the best or even the only course of action. But for customers eagerly pushing for extra features or accelerated delivery schedules for a project, being that blunt could cause problems. On the other hand, appearing indecisive or setting up false hopes may not be a good idea either.

To start with, when do you need to say “No”? In project management, a “No” is often the result of the ‘Iron Triangle’ of features – schedule – resources. If your customer wants a change in one of these factors, then at least one other element must also change. If your customer can’t or won’t accept such related change, then the answer to the extra feature request can only be ‘No’.

Communicating that ‘No’ may be done best by a short, friendly reminder about the current project goals, timeline and investment. Done the right way, a ‘No’ in this case also has two advantages. It shows your customer that you’re on the ball. It also demonstrates that you’re looking out for the customer’s interests, ensuring that the project will be completed on time and on budget.

Are there exceptions? Feature requests and schedule changes might be handled as part of an agile process, with appropriate re-planning or re-prioritization between cycles. But even with agile, sometimes it just has to be ‘No’. In that case, take the opportunity to demonstrate your professionalism and any short-term disappointment is likely to be outweighed by longer term customer satisfaction.