HOW TO GET THEM TO LOVE YOUR PROJECT

I have been really busy this summer with projects and proposals – hope your summer has been productive also.  In the midst of my to-do list getting bigger, I met a colleague online, Barbara Shannon, who had some great thoughts about getting management to support a project.  I have convinced her to write a post for us on the subject.  Enjoy!

 

HOW TO GET THEM TO LOVE YOUR PROJECT 

THIS REALLY WORKS!

“We are a war not a team. New York, Austin, Tulsa and Prague, we are each separate armies fighting to the death. We each want what we want with no regard for the business as a whole.”

This is a real quote taken from my initial interviews with a new client. Yikes! Sounds like they need a change expert, but no change readiness assessment or communication plan will put the love back in this team.

It’s CARING about and TAKING CARE of people that makes or breaks the love on a project. Take really good care of your team and your stakeholders and you will keep the love flowing right through launch and beyond. Here’s how:

You must be able to answer this one super critical question consistently in the affirmative:

IS YOUR PROJECT REALLY, REALLY IMPORTANT TO THE BUSINESS?

I’ve often thought it would be great if businesses would pick a “Project-of-the-Year”.  Imagine just working on one project a year. A project that everyone agrees is the right project at the right time for the organization.  UNFORTUNATELY it’s rare that the whole leadership team agrees about what’s most important.

Reality is that there are always too many projects competing for too few resources and creating project ADD in the business. Here’s an example of this road to ruin:

Your project is on the MUST DO list along with 40 other projects because it is the pet idea of VP X who was just brought in to “make some positive change”. None of the other VPs believe it is a MUST DO so they don’t assign any resources to work on your project.  Once they are forced to assign resources, the people they give you know their boss is not behind the project so they are not inclined to spend much time or spread the love about your project.

And if your business leads and team members don’t love the project and don’t spend much time on it, you will surely have weak requirements, crappy coding, dirty data and missing process steps plus you can pretty much expect that the users will be uninformed and bracing for the worst when it comes time to use what you’ve built.

Result: FAILURE

So what’s a project manager to do?

DON’T Just Do IT  – Put your foot down. Just Say NO! Before you commit to the project, tell the empress (project sponsor) she has no clothes.  Be the voice of reason and tell the business owners that if they are going to continue to add to your MUST DO project list, they must also agree on a STOP DOING project list. And the same goes for adding features once the project starts.

You can and should push the business leaders to get really focused about what is most important to the business and how to spend the company’s limited cash and time.

Does this sound risky to you? Well, project management is not for the faint of heart, so take a deep breath and take a stand for your sanity and for the possibility of success.  Document how many people you need and for how long and stick to it. Suggest that the leaders look at the overall project portfolio and consider cancelling or de-scoping other projects to make room for yours.

Do this at the beginning of the project. And then continue to take your stand as scope creep encroaches with every little “great idea”.  Every time the project hydra starts to grow another head, ask the business leaders to focus and choose only the most important.

Tip: It is really helpful if you can get the business leaders to agree on a short list of selection criteria that will be used to choose the top projects as well as the “must have” features.

Why This Makes the Users LOVE Your Project

Limiting the total number of projects makes a big difference and not just because focusing on just a few projects produces higher quality outcomes, but also because humans can’t focus on many things at once.  Research has proven that we actually suck at multi-tasking.  Apple does a great job of managing our limited ability to focus by offering only a few products at a time. The Apple store has only a handful of products for sale. And you can spend as much time as you want playing with them.

Imagine if we did projects this way!

Use the Apple example with your business leaders. Or stand on your head to get their attention. Remind them that they CAN do all of the projects. But the CANNOT do them all at the same time.  Business leaders know in their hearts that too many projects create diminishing returns. Someone, and it may as well be you, must help them set the stage for success by just saying no.

YOU CAN DO THIS. I’ve seen bold project managers make this case with great success. So get a credible business leader to back you up, speak with data and examples and Go For It!

—————————————

This post was written by Barbara Shannon. You can find her latest ideas and change management tools on her website, greatchangebox.com.  Her consulting company is, TSG The Shannon Group, Barbara is grateful to Deloitte Consulting for teaching her how to be the “wind beneath their wings”. She is a guest lecturer at the Wharton School and has written and taught case studies for conferences, consulting firms and executive education. You can email Barbara at barbara@greatchangebox.com

Why C-Level Managers May Fear Scrum and Agile

Implementing Scrum techniques as a project methodology (or really a framework) represents a major culture change in a traditional organization. In the beginning, the change agent, Scrum Master or Scrum champion may encounter resistance from C-Level managers because they hear the words used to describe Scrum through a different filter than developers. This difference in perception becomes greater as the size of the organization and the distance from project execution increase.

Scrum Words

What C-Level Manager May Think

Self-directed team No management or controls
Daily Scrum meetings No work will get done if the team is constantly having meetings
Product and Sprint backlog priorities determine the next set of tasks There is no over-all plan, design or Gantt schedule – will they ever be done?
Scrum team members do not have job descriptions How can individual performance be evaluated (and raises distributed) if I do not know what each individual is expected to do and how well they do it?
The Scrum team decides how much work can be completed during a sprint We bill the customer based on completion of Contract Line Item Numbers accepted — how can I predict income?
Only the product owner can change the backlog Does that mean I cannot go to “good ‘ol Paul” and get him to add a little-bitty new feature over the weekend?

In my experience there are techniques to lessen C-Level concerns about Scrum. For example, I recommend scheduling an orientation meeting for senior managers with several objectives in mind:

  • Identify the problems and challenges that drive the decision to try Scrum
  • Use numbers — how many projects deliver on time, how many complaints from customers, how often requirements change after the original contract is signed.
  • Tie problems and challenges to the cost of maintaining and upgrading
  • Demystify Scrum terms by mapping them to more commonly used concepts such as (“Scrum as Project Management” Kevin Thompson from CPrime):
  • Schedule = Sprint (or Release)
  • Scope = Sprint Backlog
  • Work Breakdown Structure = Task Breakdown
  • Productivity = Velocity
  • Estimate to Complete = Burndown Chart
  • Explain the Scrum process and framework. Show how Scrum is designed to remove some of the conditions that lead to problems in traditional or waterfall developments.
  • Reassure them about the transparency of Scrum projects and the rapidity by which problems are identified or changes accommodated.
  • Have a game plan to implement Scrum that reduces perceived risks, such as starting with a small project or prototype.

Once permission to “try it” is given, setup conditions to maximize success including:

  • Select the team, product owner and Scrum master. Send the product owner and team to Scrum classes – Like Professional Scrum Master (PSM) training. This training needs to be more than reading a book or attending a one-hour seminar — although these are a good place to start. Follow up the introduction with a formal class — usually about two days of instruction from a Scrum Trainer.
  • Provide senior management with a brief report about the training. Your goals are to provide information, reassurance and keep the interest alive.
  • Ensure that business analysts, marketing or systems people work with the product owner in the beginning to establish the vision and the stories.
  • Engage a coach to assist in the first few weeks or months who is an experienced PSM or scrum practitioner.
  • When the team understands the vision and the product backlog, allow them to self-organize including setting up work space, planning sprints and conducting daily Scrums.
  • Use the Scrum master to facilitate interaction, ensure Scrum procedures are followed and remove barriers to performance.

Give them closure

This is not a task that needs to be done every time – just during the Scrum demystification and selling phase. Either in a report or preferably a short meeting:

      • Review the reasons Scrum was assessed as an approved framework and methodology.
      • Review the Scrum terminology and the framework (events, artifacts, and roles).
      • Describe the process used. Emphasize business value of the process and the deliverables.
      • Do a demo (we call this a Sprint Review).
      • (Here’s a key item) Provide two or three, articulate testimonials from the team and the product owner / customer. What did they like. How did they feel working under a Scrum framework?
      • Have a plan that shows a progressive increase in number of Scrum projects, gaining Scrum master status for knowledgeable professionals, and ongoing staff training.
      • Ask for questions and concerns: then address those immediately, either during the meeting or within 24 hours.

For those of you who have instituted Scrum in a tradition-based organization, your observations and suggestions are appreciated.

(On a personal note – several of you had asked me to report on my certification and I passed my Professional Scrum Master test this week!)

_____________________________________________________________

Resource:

“How not to do Scrum”; New York City Scrum User’s Group

http://www.qualytic.com/sitebuildercontent/sitebuilderfiles/how_not_to_do_scrum_v4.7.1.pdf

The Lazy Project Manager's Blog

The Home of Productive Laziness Thoughts

ProjectManagement.com

Thoughts, experience, tips and tricks on issues affecting managers and project management

A Girl's Guide to Project Management

Project Management musings for one and all

LeadingAnswers: Leadership and Agile Project Management Blog

Thoughts, experience, tips and tricks on issues affecting managers and project management

Project Management Hut

Thoughts, experience, tips and tricks on issues affecting managers and project management

Herding Cats

Thoughts, experience, tips and tricks on issues affecting managers and project management

beyondcenter

Pushing the Edges Out ...

projectxpert

Just another WordPress.com site