The Real Truth About Getting Disengaged Sponsors Involved Again

Introduction

The Real Truth About Getting Disengaged Sponsors Involved Again

 

When interest levels of the project sponsors drop, it’s bad news for everyone. Bad for the business that has invested resources. Bad for the project manager and team who find themselves without an essential source of support. And bad for the end-user who may then get a product or service that doesn’t meet requirements or simply dosn’t get done.

Perhaps the wrong sponsor was chosen by the business and they were never interested in the first place. In any event is is critical to have and maintain project sponsor engagement, there is no formal methodology for doing so. Some project mangers are afraid to manage upward or don’t quite know how. Teamwork between the project sponsor and project manager is the way to create really effective projects.

Here’s a few suggestions

  • Common sense – Make sure you think your tactics through
  • Understand your sponsors perspective, agenda and how it does or dosn’t align with the project goals
  • Seek to understand why disengagement has set in, workload, disapproval of change, people issues
  • Communicate – as a project manager you are a senior staff member and tackling the head-on may be the way, Let the sponsor know you need the support

If you still cant get a re-engagement don’t undermine the sponsor but perhaps seek out other stakeholders that can provide the necessary support in the organisation. This can be often be done with the permission and support of the main sponsor. Particularly if the disengagement has happened as a result of workload.

If you are still stuck and the project effectiveness is being undermined you will need to go all the way to the top.

 

 

Why Going Agile And Embracing Change Is Easier That You Thought

Introduction

Why Going Agile And Embracing Change Is Easier That You Thought

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.

Quick Tips For Scrum Meetings That Work

Introduction

Quick Tips For Scrum Meetings That Work

 

Make no doubt about it the early scrum (Planning and Daily)  meetings set the tone for all the following activities of the project. With Scrum, life cycles are short and the pace hot with little time afterwards to re-jig team attitudes and behavior.  With the early meeting setting the tone for the rest of the cycles I suggest that you create an additional scrum kick-off meeting.  This can help to ensure that subsequent scrum meeting are focused on the scrum job and not the “ground rules”

This Scrum kick-off meetings gets the getting to know how it works out of the way. Subsequent team meetings will need to be rapid stand-up ‘huddles’ lasting for all of 15 minutes, you don’t want your kick-off meeting to seem too leisurely. Yet you also want to take enough time to set the scene properly for future success. The following tips may help:

  1. Remember that Scrum is also about trusting people’s ability to solve problems. The team may be the best source of answers for some questions that arise.
  2. Make sure your whole project team is there, for full input and engagement. Change the date to accommodate anyone who has a schedule conflict.
  3. Notwithstanding quick-fire project meetings in the future, allow plenty of time for the kick-off meeting.
  4. Make sure team members get to know each other. Fun exercises and games are one possibility.
  5. State or remind the team of how Scrum works and the roles of the Scrum Master and project team members.
  6. Agree on definitions (when is a deliverable truly ‘done’) and project tools (specific project management and issue tracking software, for instance).

When you get steam up on your Scrum process afterwards, remember that from time to time, it’s good to have periodic get-togethers along similar lines to the kick-off meeting. This can be an important factor in maintaining team enthusiasm, cohesion and momentum.

 

Scrum Values

Introduction

Scrum Values

Scrum Values apply to all the team not just the Scrum Master or Product Owner and they are Values that can be effectively applied to Agile and traditional waterfall methods. When moving from waterfall to Agile there values are the first thing for the Scrum Master to get the agile team to buy into.

Focus – Team focus and Sprint goals are important responsibilities for the Scrum Master. The Scrum Master should remove impediments from the Team and protect the Scrum team members from external influence.
The Product Owner and Scrum Master should be responsible for ensuring a well groomed backlog which is both estimated and ordered and the team should be fully be focused on delivering the work committed to in the sprints.

Courage – The Team member must have the courage to speak out and ensure that their contribution is heard but with an openness other. The. Scrum Master needs to have the courage to negotiate with stakeholders and the Product Owner when it’s right to do so!
Whilst at the same time the Scrum team needs the courage to commit to as much work as possible within the Sprint whilst respecting the definition of done.

Openness – This is a core Scrum Value that makes Agile so much more effective than traditional management.
The Back log should be fully qualified and visible so that everyone is aware of what work is up and coming. The retrospective must be fully open with problems openly discussed

Commitment – The Scrum team commits to what they will complete each sprint. They also commit to how the work will be ‘done’ and to meet the Definition of Done.
The Team commits to doing whatever is collectively necessary in order to meet their goals. The wider organisation also commits to support the scrum team and to respect the values of Agile.

Respect –This is perhaps one of the important values in Agile… And sadly one that I often observe is not followed! The Product Owner gets to dictate what work gets done and in what sequence – And it’s the responsibility of the Scrum team to respect those decisions. However The Product Owner must trust and respect the team to decide how they will accomplish this and respect the team when they push back or if they believe the Product Owner is encouraging them to overcommit. The Scrum Master should be aware that they are not management but the servant leader responsible for ensuring that the Scrum team is able to run at maximum efficiency and to coach stakeholders, Product Owner and the Scrum team on all things agile!

At Althris Project Management Training we have some tool and Agile games to help get the team focused on these values. For further reading I suggest you look to see what Ken Schwaber says about the Scrum Framework for software development.

PMI-ACP, Agile, PMP, Scrum, Agile Certified Practitioner

Introduction

PMI-ACP, Agile, PMP, Scrum, Agile Certified Practitioner

The PMI-ACP is not difficult  but it does throw up some strange questions as the PMI try to relate the traditional PMP material to the  Agile methodologies. Many of the analysis techniques like  earned value are difficult to related to software development in a waterfall environment and applying them to agile seems like an unnecessary overhead we have no BAC.  The good news is that it is all due to change.

The current exam focuses on Scrum , Lean, Agile Concepts (the manifesto)  Kanban and XP and then mixes them up to create situation questions relating to general management or Project management (servant leader, Emotional intelligence etc.)

Mike Griffiths book is still the best general book, though I don’t think it gives Lean the coverage that is needed for the ACP Exam. Be careful with the online PMI-ACP exam question available online as  many of them are absolute rubbish, frustratingly written in an unknown dialect of English with confusing or completely incorrect answers.

The Velocitech website is probably the best set of exams out there and Andy Crowe’s  book is a good reference book with exam questions for the ACP exam but it is not a complete guide.

I do suggest that you research Mike Coen (Scrum) and  Mary Poppendieck (Lean) material. Their  publication,  webinars and blogs are a good source. Ken Schwaber book the “the art of doing twice as much in half the time” is worth a read for motivation though not particularly useful ACP

The books if you have the time are:

The Project Management Institute suggests a number of others on their website. These have changed from the previous exam  with 4 new books added and 4 removed. 2 are on Kanban alone.

The exam time is 3 hours with most of my student competing it in 1.5 hour and many in less than an hour. The question are not as tricky as the PMP exam, correct answers are more obvious and less where the answer required is the ‘‘best’ or ‘first’. Moving from agile concepts will catch you out, one minute we are taking about the customer, the next it’s a product owner and the next question may be from the point of view of a Project Manager.  

The course is a good course to get yourself up to speed as a traditional project manager, a middle manager or perhaps as a product owner. For developers or budding Scrum Masters It may not provide the level of detail and doesn’t deliver the ‘fun’ experience that agile encourages.

The course is changing with a different approach. It looks to me like it will concentrate more on the approach and mind-set and less on the specific concepts.  I suggest that it will aligned with the directions that the PMI have for the skills of  a combination of technical, leadership, and strategic and business management expertise.

The new PMI-ACP exam will see a number of changes (PMP Exam Content Outline,) summarised below.

There are sever domains of Agile practices:

    1. Agile Principles and Mindset
    2. Value-driven Delivery
    3. Stakeholder Engagement
    4. Team Performance
    5. Adaptive Planning
    6. Problem Detection and Resolution
    7. Continuous Improvement (Product, Process, People)

The distribution of questions on the PMI-ACP exam paper are now based on the domains

  1. Agile Principles and Mindset – 16%
  2. Value-driven Delivery – 20%
  3. Stakeholder Engagement – 17%
  4. Team Performance – 16%
  5. Adaptive Planning – 12%
  6. Problem Detection and Resolution – 10%
  7. Continuous Improvement (Product, Process, People) – 9%

New Tools and Technique / Knowledge and Skills are added while many are removed from the new PMI-ACP exam syllabus. New items added including:

    1. Developmental mastery models (for example, Tuckman, Dreyfus, Shu Ha Ri)
    2. Participatory decision models (for example, convergent, shared collaboration)
    3. Agile hybrid models
    4. Managing with agile KPIs
    5. the Five WHYs
    6. retrospectives, intraspectives
    7. control limits
    8. pre-mortem (rule setting, failure analysis)
    9. fishbone diagram analysis
    10. minimal viable product (MVP)

Althris Training have worked with our partners to redevelop our course material for the new ACP exam. To keep you posted and get more updates on both drop me an email.

User Stories – Invest

Introduction

The Six Attributes of a User Story and Why They All Count

The current best practice in Agile Software Development to clearly and briefly describe the functionality from the end-user’s perspective is the User Story. High quality User Stories will become part of the product backlog iteration. Weak User Stories are a waste of time and should be avoided at all cost.

This article will teach you the six attributes every effective user story must possess to pass the backlog quality check and ensure you spend your time right.

The INVEST Mnemonic To Writing High Quality User Stories

This simple, yet profoundly powerful mnemonic is a creation of Bill Wake the co-inventor of Extreme Programming.
I = Independent
A great User Story has the potential to stand for itself. By following this criterion the story can be scheduled and implemented in any desired order. This makes the story usable in different contexts and for multiple concepts.

N = Negotiable… and Negotiated
Outstanding User Stories are co-created by the programmer and the user. Only the main essence is captured, while the details are steadily added and influence the whole backlog in an iterative manner.
V = Valuable
All great stories add specific value to their target audience, in this case: the user. Especially when splitting stories, each individual piece should address one very specific area in which value is created, while telling the overall conceptual story.
E = Estimable
Every User Story must be estimable in order to be considered for a ranking by the customer. The degree of ratability is directly linked to the story being negotiable. Only stories that are understood by all stakeholders are estimable in scope and budget.
S = Small
A Story should not be overwritten and only focus on one key value adding idea. Keeping it within the range of a few person-days and at most a few person-weeks ensures that the story will be estimable.
T = Testable
Stories must be testable in order to be considered for the product backlog. If a story is not testable due to a lack of information it probably is not estimable and does not provide specific value to the customer.
All of the six attributes have to be considered in order for the User Story to be implementable. They affect each other in an iterative manner. Shortcomings in one area may lead to an information deficit in another and towards an unusable story.

Take the time to check your User Stories for all of these attributes. Time has shown that a Feedback Circle of Proposing – Estimating – Implementing is the most effective way to produce a great User Story, implementable in many different contexts.

Where to with the user story when completed
A user story is typically functionality that will be visible to users, by users this includes end users, administrator’s manager. To create a user story will require a number of tasks to be completed. These tasks are often shared out among a range of people such as analysis’s, designers, programmers and testers so each has their own task. When put together the tasks complete the user story.

User stories appear on the Product Backlog and tasks appear on the sprint backlog.

Include INVEST workshops as part of good Scrum Master training and coaching.

Agile – Back to Basis

Introduction

Back to Basics: When was the last time you looked at the Agile Manifesto?

The Agile Software Development method was officially introduced in 2001 (http://agilemanifesto.org/). However, evidence of similar incremental software development methods dates back to as early as 1957. The recent hype due to the method’s continuous improvement and rapid development led to confusion and information clutter.

It is time to take it back to the basics today and focus on Agile’s core values.

Honestly, when was the last time you looked at the Agile Manifesto? If this has been a while ago, here is a quick summary to refresh your memory and help you focus on the core conceptual framework.

The Agile Manifesto – The Key to Success in Agile Development

The manifesto was laid out in February 2001, when 17 software developers met in Utah to discuss lightweight development methods. The results have been groundbreaking. Here are the main values and working principles.

The 4 Core Values of Agile
In order to uncover more user-friendly ways of software development, the following values have been announced.

Individuals and Interactions > Process and Tools
Working Software > Comprehensive Documentation
Customer Collaboration >  Contract Negotiation
Responding to Change > Following a Plan

Are you following these core values in your recent Agile project? If not, do not be surprised if the project lacks in success.

The 12 Core Principles of Agile

1: Customer Satisfaction: Develop valuable and useful software quick

2: Welcome Change: Make changes during all stages of development

3: Frequent Delivery: Produce little working chunks of software constantly

4: Close Cooperation: Co-create the software with all stakeholders

5: Motivate Individuals: Develop a working atmosphere of mutual trust

6: Direct Communication: Talk to involved parties face-to-face as much as possible

7: Working Software: Produce software that creates results

8: Sustainable Development: Maintain a constant development pace

9: Continuous Attention: Focus on technical excellence and good design

10: Simplicity: Maximize the amount of work not done

11: Self-Organization: Allow teams to self-organize around their strengths

12: Regular Adaptation: Adapt to changing circumstances

 

These principles can be applied to almost all processes of your business. In Agile, they are crucial towards the efficient and timely achievement of real results.
These core values and Principles are vital to the implementation of an agile process, it is essential that you regularly look to these principle to ensure you are not just following a process but truly building an agile environment.

Scrum Master Is Not A Project Manager

Introduction

Scrum Master Is Not A Project Manager

The Specific Reasons Why a Scrum Master is Not a Project Manager

Companies new to Agile often fall into the crucial trap of mistaking the Scrum Master role with the role of a Project Manager. This often leads towards a dramatic detriment in productivity, since the Scrum Master role requires a very specific skillset which is entirely different from the more generalist role of a Project Manager.
This article will point out the main differences between those roles and help you to chose the right person for both positions to make your project a success.

The Classical Role of Project Management
The Project Manager leads the project on a day-to-day basis, controls, communicates and provides direction. His role can be summarizes into the four following categories:

1: Manage Processes: The Project Manager gets the project “up and running”, selects the team, establishes milestones and project schedules with the team and leads the project on a daily basis

2: Track Process: The Project Manager monitors the timely achievement of milestones, tracks team costs and investments, overseas the documentation and provides direction

3: Facilitate Cross-Functional Collaboration: The Project Manager Identifies linkages between sub-projects and coordinates cross-team cooperation

4: Communication: The coordination of key project-related messaging to internal and external audiences, as well as communicating project information to the line management are Project Management roles

 

The Specific Role of the Scrum Master

The Scrum Master on the other hand does not manage the team on a daily basis. His role is more of a coaching and a facilitation role regarding Scrum, which makes him the link between the project team and the client.

Scrum Masters cooperate closely with the Executive Sponsor. They ensure that the project complies with Scrum and that all processes are implemented properly. The role can be summarized into the 3 following categories:

1: Overcome Stumbling Blocks: The Scrum Master steers the development, resolves problems and involves the right people in the development process

2: Oversee the Groundwork: The Scrum Master keeps two eyes on user experience, functionality issues and feedback from all stakeholders

3: Provide Guidance: Helping to facilitate changes and assist in the planning process while providing overall Scrum guidance is a crucial function of the Scrum Master

There you have the main difference:
The Scrum Master is there to help and assist with highly specific technical knowledge but not to manage the workflow.

 

Summary: The Scrum Master is not a Project Manager
The role of the Scrum Master is more specific and technical than the more general role of a Project Manager. Both are important. Confusing these roles however almost certainly leads towards failure in the execution of Agile – and towards huge losses.
Make sure you have these important positions covered with the right people.

scrum-training-638x321

Is Estimating A Waste Of Time

Introduction

Is Estimating A Waste Of Time

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.

Project Sponsorship

Introduction

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

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.

#iguru_soc_icon_wrap_5f9415a5a48f2 a{ background: transparent; }#iguru_soc_icon_wrap_5f9415a5a48f2 a:hover{ background: transparent; border-color: #116cb6; }#iguru_soc_icon_wrap_5f9415a5a48f2 a{ color: #acacae; }#iguru_soc_icon_wrap_5f9415a5a48f2 a:hover{ color: #ffffff; }