Skip to main content

Tag: Career

From the Sponsor’s Desk – Create Your Next Great Assignment

Written by Drew Davison on . Posted in Articles. 1 Comment on From the Sponsor’s Desk – Create Your Next Great Assignment

Despite all our gains in technology, product innovation and world markets, most people are not thriving in the organizations they work for.” Stephen Covey

How long have you been doing your current job or filling your current role – project manager, change manager, etc.? Are you getting bored with the assignments? Would you like to try something new and different? Would you like new challenges? Then keep reading to see how you can create your next great assignment.

The Situation

A former colleague of mine, let’s call him Terry, was a very knowledgeable and successful technology architect. But he was getting bored with the role. He wanted something different, something new, a bit more stimulating. He needed a change.

As Terry was contemplating new opportunities, his boss, the CIO, handed him a ticket to an upcoming conference and asked him to see if there was anything to the new technology the conference was targeting – artificial intelligence. Obviously, this exchange took place a while ago. But Terry did attend. The timing was right. The subject matter was ideal. And the forum was perfect for establishing outside contacts and building relationships with experts in the field.

Terry returned to the office and mulled over what he had learned. As he was contemplating his next steps, the CIO departed the company. Now he had to sell the VP of Finance, who was not technically savvy and who Terry had never dealt with before, or wait until a new CIO was appointed. Terry decided to charge ahead.

The Search for the Next Great Assignment

As it turned out, the CIO’s departure was a blessing in disguise. Terry had to rework his whole approach. He had to change his focus, from the technology that was initially at the heart of his proposal to the business opportunity that would appeal to the VP of Finance. Instead of emphasizing the various technologies, he would promote Fast Change – delivering real business value quickly with bankable returns.

Terry realized the biggest challenge for his prospective business clients was getting stuff done. There was at least a three year backlog of projects in the traditional system development cycle and the methods and practices they employed meant big price tags and long delivery times. Many of the opportunities Terry wanted to focus on were small initiatives with potentially large impacts that were typically outside the core system development mindset and planning process.

So Terry put together his proposal for the VP of Finance’s consideration. He outlined the burning platform that was at the heart of the proposal – the number of business opportunities that were not being serviced by the major system development life cycle. Terry included a number of examples business managers had provided to him during his research. He proposed a small Fast Change team that would solicit assignments from the across the organization. It would accept projects that offered a 3:1 return, $3 for every $1 invested. It would be nimble and quick, focus on business need and deploy whatever technology and practices were required to support the benefit and cost goals. The business would be on the hook for benefit realization. Terry’s team would be responsible for managing costs in line with the target ratio. Projects that were accepted would deliver benefits within six weeks and would not exceed six months for all phases. All projects would be audited by Internal Audit on a rolling quarterly basis. Each project would go through an internal gating process and projects that failed at any of the gates would be relaunched or go through an early exit. Terry’s proposal also presented some alternative implementation schemes and growth scenarios to respond to the anticipated demand.

Terry reviewed his proposal with a number of trusted colleagues and then booked a meeting with the VP of Finance. He was confident in his material and the value of his proposal but he was unsure how it would be received. He needn’t have worried. The VP of Finance loved the business focus, the emphasis on nimble, fast delivery, the 3:1 benefit to cost ratio, the quarterly audit. He saw it as a low risk, high return venture that would enhance business confidence in IT and compliment the other core IT services. He gave Terry the go ahead for a four person team.

Advertisement
[widget id=”custom_html-68″]

The Results

Terry wasted no time getting up to speed. He assembled his four person team and together they began to socialize their service. They spread out to the various management teams throughout the company to introduce Fast Change. They conducted Lunch & Learn sessions over the lunch hour, offering sandwiches and crudité as enticements, open to all. Recognizing that their IT colleagues also had numerous contacts throughout the business, they encouraged them to promote the Fast Change service and pass on any leads.

In very short order, there was more work than the team could handle. They negotiated among the competing requests and selected two projects to tackle concurrently.  The initial efforts were light on methodology and documentation, using a project charter-like document as the mandate letter and relying on close collaboration between the team players – business, Fast Change team, IT resources and consultants as needed. Also, some of the initial technology search, selection and integration activity took longer and cost more than anticipated and the VP of Finance agreed to offload some of the cost from the initial project on the proviso that subsequent endeavours would benefit from the work. 

The first two projects were delivered successfully with enthusiasm all around. The word spread. Two more projects were selected in quick succession, followed by three more, and on it went. The order book was growing rapidly and a backlog developed. At the peak of operation, the Fast Change team had about thirty concurrent projects on the go at any one time and delivered over 150 projects over the team’s life. The full portfolio achieved in excess of the target 3:1 benefit to cost ratio with each individual project delivering a minimum 2:1 benefit to cost return.

Fast Change team members loved the experience. They were working with new and interesting technologies and engaging directly with the business members. They were talking to outside experts about new approaches and technologies that could help them solve today’s business problems. The business participants raved about the experience because they were working directly on and solving their business problems in the short term. The VP of Finance was most enthusiastic for the initiative. He was getting rave reviews from the executive offices and delivering the promised return on investment. And Terry was thrilled as well. He got to create and enjoy a stimulating and profitable experience.

How to Create Your Next Great Assignment

Terry went from a high performer in his technology architect role, to a novice Fast Change artist, to a rapid change master. His team went through the same learning cycle. And they all thrived. There were a few keys to their success – a willingness to learn, to try something new, a supportive and collaborative culture, willing and able business participants, a supportive sponsor and, of course, the golden opportunity.

The steps Terry went through are similar to the approach you’d take to launch a start-up venture. In fact, my previous post, Run Your Project like a Start-Up, covers a similar journey. If you’re keen on going after a new and different assignment, here’s the approach Terry used. Refine it as you see fit:

  • Explore – What are you good at? What do you enjoy doing? What technologies, processes and practices look interesting from your perspective? This stage is all about changing your frame of reference, from what you have been doing and are doing to what you could be doing in the future.
  • Research – Pick a few items from the Explore stage that appeal to you and do some research. Who is leading the way? What are they achieving? Does the timing put you on the bleeding edge? What’s the learning curve like? What’s the timeframe for delivering value? What’s the approximate size of the investment to get started? Would the field be of interest to your current organization or would you have to move to pursue the opportunity? The Research stage should help you narrow down your options and pick one or two possible directions to focus on.
  • Pitch – Develop your pitch. Target it to the individuals who will decide whether to fund you to the next step. Cover the burning platform/opportunities and the solution/secret sauce you believe will reap the rewards. Present alternatives for your offering and how to get there. Demonstrate market validation (who’s doing what) and include examples. Show the potential market size (magnitude of opportunity). Include the key selling points that address the burning platform and capitalize on the opportunities. Present the value equation – 3:1 benefits to costs in this case – plus other tangibles and intangibles. Cover the metrics, measurement and control practices that will ensure the targeted return. Present your market adoption strategies and options. Address the competition for your job, role, product or service and your and their competitive advantages, weaknesses, opportunities and threats. Present your team, either the real people or the skills and capabilities needed. Lay out the next steps to get you on your way and delivering that value you promised. Put all this in a nice slick, short, succinct package with key pictures, charts, tables, graphs and graphics. Socialize your draft pitch with friends, family, your mentors and colleagues and refine accordingly. Finally, make the sale. Repeat as necessary.
  • Resource – In Terry’s case, his new assignment required additional staff and resources. The people he picked would ultimately determine the success of his venture. So he chose carefully. If your new assignment requires additional resources, be very clear on the knowledge, skills, attitudes, aspirations and capabilities your team will need to be successful. And proceed accordingly.
  • Trial – Once you’ve received the go ahead, pick a couple of tasks/projects/engagements – some low hanging fruit if you will – to prove the concepts, provide the training and learning opportunities and demonstrate the value to your clients and sponsors. Refine as needed. Repeat.
  • Promote/engage – Your target audience and your sponsors need to hear about the value you can provide and have provided to others. Use lunch & learn and information sessions, flyers, blogs, Youtube videos, face to face one on ones, whatever is appropriate and effective for your market. Also, tell your success stories. Or let the business partners who reaped the benefits of your efforts tell the stories for you.
  • Manage – This is where the rubber meets the road. Measuring your performance will make you better and your team more focused. Make sure you’re providing the value you promised, like the 3:1 benefits to costs, internal gating, early exits and quarterly independent audits in Terry’s case.

So, ask yourself what you’d like to do for your next assignment. As you consider that question, consider Terry’s challenge and the path he followed to a stimulating and fulfilling new assignment. I hope you too can create your next great assignment.

Project Management Strategies for Succeeding in the Fashion Industry

Written by Jennifer Hahn Masterson on . Posted in Articles. 5 Comments on Project Management Strategies for Succeeding in the Fashion Industry

The fashion industry is one of the fastest-growing ones and it’s probably more unpredictable than any other.

What is “hot” today may easily not be popular tomorrow, which makes it very difficult to plan for very long periods in the future. Still, this industry needs people who know how to manage all its aspects and we can only admire them for their skills.

What people see are models showing the latest fashion trends on the runway. Some are relatively conventional, while others are quite eccentric and we enjoy looking at these works of art, but we probably don’t know what is going on behind the scenes of a fashion show. Instead, we simply admire the final result. For this result to be achieved, teams of people have worked tirelessly for months to prepare such an event and they had to be managed properly. To help you understand what happens behind the scenes, we’re prepared this list of the crucial project management strategies for succeeding in the fashion industry.

Stakeholder management

This refers to your knowledge of the market and customers, as well as your ability to successfully deal with a number of stakeholders who have an impact on your company. The list is quite long and includes, among others, trade organisations, suppliers, sponsors, partners, buyers ad distributors. If you want your company to grow and be successful, you have to establish a transparent collaboration, which facilitates excellent communication with all of them.

Planning

There are many different types of projects in fashion. They range from opening a shop (physical and/or online) to product launch, organising a fashion show or entering a new market. Each project requires a plan that will turn your vision into reality. You need to have a plan that factors in all the vital steps to reach your goals. This is one of the trickiest things, since the fashion industry is moving fast, but that doesn’t mean you can’t plan. Actually, it means you have to devote more attention to planning, because you want your company to produce new fashion items as successfully as possible. With the fierce competition in the industry, this task is harder than ever, which only makes it more important.

KPIs

Each process needs to be analysed to ensure the project is efficient. However, knowing what, when and how to analyse is quite a challenge. The key is analysing relevant aspects, eliminating human bias and producing actionable data that can be used for preparing, planning and managing projects. Choose the minimum of indicators that reflect crucial parameters and trends, such as time, cost & revenue, work efficiency and work quality to get a clear picture of the direction your project is heading. Forward-thinking companies are now using a digital marketing dashboard to automate the process of data collection and processing, thus saving a lot of time.

Advertisement
[widget id=”custom_html-68″]

Risks and changes

With changes happening constantly in the business, it’s vital you stay on top of your game at all times. No matter how long your company has been successful, it you fail to anticipate future trends and identify challenges, you won’t stand very good chances of surviving. That’s why fashion companies have to identify possible risks (production failures, supply chain errors, etc.) and be prepared for sudden changes (demand change, regulatory changes etc.). Also, they should be aware that customers are much more conscious of the social impact of fashion’s pursuit of producing clothes as fast as possible. It’s true that producing cost-efficient items is important, but negative media coverage can have a devastating impact on any business and ruin a brand’s image. Hence, you need to wage the risks and benefits carefully and balance them out.

Agility

It’s very important that a fashion company and its management are agile and flexible. This means that processes, such as sales, customer management or supply chain management will be more efficient, i.e. lead to higher and faster turnover of products and better position on the market. Agility also encompasses the notion that project teams work and collaborate more efficiently. All this is eventually translated in boosted reputation and improved business results, which are the goals of every company in the world. Going by what a new Bachelor of Arts in fashion design at Raffles Milan teaches its students, the fashion system is a huge, articulated, often unpredictable territory, where a sense for the classics manages to find common ground with the extremes of experimentation.

Teamwork

A lot has been said about the importance of teamwork, and fashion companies should know it better than most other businesses. Any misunderstanding or problem in communication can have detrimental effects on the outcome. That’s why it’s important to have regular review meetings to discuss decisions and analyse processes. Every team member needs to know exactly what their responsibilities are. We can’t stress enough how crucial communication and collaboration are in the fashion industry. The ultimate goal of producing a clothing line as efficiently and quickly as possible can’t be reached unless everyone involved works together effectively.

These strategies are very important for most industries, but when it comes to the fashion industry their role simple gets more important. That’s why every project manager should be aware of them and apply them in such a way that they help the company reach its goals.

Pulling Value

Written by Paul Antelman on . Posted in Articles. 7 Comments on Pulling Value

There’s no turning back.

It’s not whether a company’s IT functions are agile or not, it’s whether they are “really” agile, how they are agile, whether they can “scale” agile, whether they have adopted continuous integration, are a true DevOps shop, and on and on. With this sea change there are victims; methods and paradigms that look hopelessly out of touch and frantic in their attempts to keep up with the times. My company recently dropped the requirement to be certified by the Project Management Institute as a prerequisite to earning their own internal certifications for engagement management. ITIL is reinventing itself as I pen this missive, claiming they never promoted a particular “process” and blogging that “ITIL can be agile” practically as an apology.

In some ways, this reaction is unfortunate. What we’ve learned from the shiny objects of decades past—Lean, ITSM, BPI/BPM, PMI, Requirements traceability—still has real value to offer value to today’s IT environments. Much of what we’ve learned still offers insight on how to get work done that needs to be done.

Let’s give agile credit where it’s really due… not to the planning poker cards, the shirt sizing, the scrum boards, sprint length, the bake sales, the epics/features/stories/, the pigs and chickens, the BDD / TDD, the “get to done” mantras, the anti-documentation, the “no deadlines” nor to its latter day offspring of continuous integration and DevOps, but to core principles that make agile a truly valuable contribution to the way we do work. If we changed nothing about the trappings of how the corporate polity does IT but adopt several important principles of agile, organizations will truly transform in important ways that will shake off some of the lipstick we’ve been putting on pigs’ lips these past few years.

The first, and most critical, principle is to pull value. This is to contrast with pushing scope. If the organization truly emphasizes, and puts controls in place that enforce that emphasis, on doing only what is valuable, doing what is most valuable first, and honestly, continuously, assessing the value of previously sacrosanct IT practices, then it will be a more agile organization.

More agile than what? More than one that has implemented every metaphor of SAFe and managed to retain all of its middle managers in the process, as the program increments of its months old project plans yellow with non-valuable age. Or more valuable than stoplight status reports without plans of action, just like typical issue / risk logs. Or adding layers and layers of functional testing, possibly at the expense of doing more pertinent testing, like security scans and performance testing that address what users in today’s environment need to have be true about their software.

So how do we pull value? It really boils down to hard work, especially from the business. Software is never an end in itself (unless you’re a software vendor, and then you only exist because of a marketable business need). The agile principle that “business people and developers must work together daily throughout the project” is a literal principle. It’s a daily thing, there’s no work around. I know I’m challenging the hard-core agilists here, but I would also suggest that the efficiency gained by insisting on only one product owner as a conduit for evaluation of all that is valuable might be over-emphasized. If the product owner shows any sign of lacking the insight and/or necessary feedback cycles to know what is valuable, or worse, is over-assigned with other work, then the development team needs to work at getting the value verdict from all possible sources before doing the work. Every single requirement, every single story, needs to be subjected to the question “what is the cost of doing nothing?” It is not true that agile is not cost-conscious. It is not true that agile is easy. Simplicity is not easy.

Advertisement
[widget id=”custom_html-68″]

This of course means that the principle of “welcoming changing requirements… [to] harness change for the customer’s competitive advantage” needs to be embraced. Don’t stop efforts to “scope out” a complete solution when deciding that software (or any “ware”) needs to be built, but appreciate that much of what you think is important today can and will be on the cutting room floor tomorrow. It’s always a good idea to think about and study a business problem to determine if the problem is really even solvable with software. The notion of “start with an index card and write code on day one” is romanticized and a bit silly. But rework is like death, taxes, and the weather. You won’t avoid it, so minimize its deleterious effects by continuing your gravitation to what is truly valuable.

What I have found in my coaching assignments is that if we start with structure and constraints—how long will our sprints be, do we use points, should we do Gherkin, how many testers do we need on a scrum team—instead of principles—what will promote inspection, adaptation, and transparency, do we build around motivated individuals and do we trust them to get the work done, and are we maximizing the work not done?–  then we get results that resemble the very real problem of having the cart positioned ahead of the horse. Time is always precious, and you’ll risk not having enough to get to teaching, promoting, and implementing right principles. So start there.  

The power of Covey’s “Seven Habits” is really its admonition to live a principle-based life, and the wonderful thing about agile is that it is girded with great principles. The four manifesto tenets, the five values, the three pillars, and the overriding almighty law to “do what makes sense” are exactly what really matter to achieve an agile transformation.

Becoming agile requires a sea change in the hearts and minds of people who run organizations. Frankly, the growing prevalence of “solutions” that scale agile are too often thinly veiled attempts to preserve mechanisms that reflect old ways of thinking—most poignantly, of preserving management functions that simply don’t contribute[i] value. The old-schoolers have been steeped in the cult of scope. “Scope creep” needs to become a meaningless concept because we’re not slaves to scope any more, we’re evangelists for value.

Focusing on pulling value doesn’t de-value the lessons we learn from ITIL about running IT and delivering customer-centric value every day, or the importance of recognizing and mitigating risk that PMI teaches. Budgets are still important and all the skills of bottom up estimation and planning based on available resources are needed. It’s PMI’s emphasis on some holy place for “full scope” that need to be deprecated, not all of the valuable management skills PMI demands and tests for in its grueling PMP exams. You can have the best hammer and be motivated to use it, but you still need to know where to put the nail and understand how many you have available to build the house. Expectations about when and for how much are still important.

Start with value, end with value, and every day self-examine what you are doing to provide value by asking if what you’re doing is the most valuable thing you can do today, given time, resources, and the needs of your customer. If your organization can do that together, it’s already transformed. [ii]

 

[i][i] The Agile Manifesto, from  Kent Beck; James Grenning; Robert C. Martin; Mike Beedle; Jim Highsmith; Steve Mellor; Arie van Bennekum; Andrew Hunt; Ken Schwaber; Alistair Cockburn; Ron Jeffries; Jeff Sutherland; Ward Cunningham; Jon Kern; Dave Thomas; Martin Fowler; Brian Marick (2001). “Manifesto for Agile Software Development”. Agile Alliance. Retrieved 14 June 2010. [i]

[ii] Scaled Agile Framework, from Leffingwell, Dean (2007). Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley. 

How to write a data-driven resume

Written by Ron Boaz on . Posted in Articles. 7 Comments on How to write a data-driven resume

As business professionals, we know the increasing importance of data-driven decision making in our projects and operations.

This article will explain why we need to bring that same approach to resume writing, and how to level up your Project Manager/Business Analyst resume writing skills.

The importance of data

In the business world today, it is hard to come by important decisions that are made in the absence of data to support them. Managers are, understandably, loath to not have evidence stacked up to support a claim or decision that exposes their organization to opportunity, but also risk. 

This same perspective can be applied to hiring decisions as well. Are not employees a huge opportunity, albeit potential risk, for any business? A star employee can transform an organization for the better, resulting in a strong bottom line and happier customers. In a competitive job market, candidates need to sell their attributes and accomplishments to hiring managers, who increasingly need to base their hiring decisions on strong evidence, not unlike other operational or project decisions. Show me the data!

What does this mean for your resume?

For one, your resume needs to be quantitative. Most resumes list work experience and education in a neat table, sorted by date and organization. This is a good start. However, when you drill down into the details (the bullet points) underlying each previous job, the descriptions often leave something to be desired. For example;

  • “Compiled project analysis for company executives”
  • “Managed an organization-wide ERP solution implementation”
  • “Trained support teams on use of new software tool”

What these examples demonstrate is a lack of volume, scale, or size. How is a hiring manager to know if you managed the roll out of an ERP system for a staff of 10, or 2000? What does improved service delivery really mean? That each agent more consistently said thank you at the end of each call? Or were turnaround times reduced by 30%? Look for your ‘wins’ and highlight them with data.

What this can look like:

  • “Comprehensively analyzed and compiled dozens of address, routing, and fuel data points on a weekly cadence, to draft executive reports that could be quickly understood and acted upon”
  • “Managed a 1 year ERP implementation affecting 900 staff, resulting in time savings of 5 FTEs”
  • “Facilitated dozens of training sessions of 5‐25 participants each, achieving an average instructor rating of 4.5/5 from feedback forms”

There are 2 important take-aways from the above examples:

  1. Fully use the real estate provided to you on the page. Your resume should only be 1-2 pages, so use up that white space as efficiently as possible.
  2. The examples use specifics that are quantified.

Examples of other metrics you can use:

  • $’s spent, saved or earned
  • Time taken or time saved
  • Cadence or turnaround time of process or task
  • # of people impacted, trained or involved
  • # of computers/machines updated or provisioned
  • Volume or quantity of materials 
Advertisement
[widget id=”custom_html-68″]

Is the data impressive enough?

What if the numbers aren’t impressive, you may ask? When providing feedback on resumes, mentees often state they don’t think their accomplishments sound big or important enough if too much detail is given, as if keeping it vague somehow augments their work. If you don’t think an accomplishment is worth quantifying, remember that hiring managers can also revert to the lowest common denominator, if quantities aren’t provided. You may have concurrently managed 10 accounts worth an average of $10,000. In the absence of concrete numbers, a hiring manager may theoretically guess that maybe it was 4 accounts worth $5000 each. 

Sometimes, exploring different ways of telling your data story can make your work history sound more effective too. Maybe you successfully negotiated a $100 savings on a monthly vendor contract. That’s great, but maybe you can re-word it as, “Negotiated a 10% savings on a recurring monthly expense, saving $1000s per year”. Explore absolute versus percent versus ratio metrics for each claim, as sometimes one will sound better than the other. 

Internal- and external-facing data points

You may notice 2 distinct metrics types, that we can call internal, vs. external. Often, when we are stuck in the weeds of our projects, we only think of our internal metrics. These could include things like # of stakeholders managed, dollars spent, or groups involved. What are often more impactful, in terms of convincing employers of the significance of your work, are metrics that speak to what your project ultimately accomplished; the downstream outcomes. Sometimes, these data points may not be known for months or years. These could include things like # of new clients, # of people trained, or incremental dollars earned or saved, directly due to actions you took while deep in the weeds of your project. Have a think about your last few projects. What were their downstream outcomes?

Quantify your interests

People differ on the utility of a personal interests or extracurricular section of your resume. I’m personally a fan, because hiring managers are hiring people, not robots, and want to know who the person is that they are hiring. Also, hiring managers, like all humans, are subject to nervousness around meeting new people in a formal interview setting. The personal interests section provide great small chat talking points to fill otherwise awkward pauses that can occur before and after the formal questioning part of an interview.

Just like with the other sections of your resume, be specific, and quantified, with your personal life! Instead of; 

  • “Organizer of musical festivals”, or 
  • “Love travelling and photography”

you could say

  • “Have organized 3 musical festivals with 1000s of participants each”, or
  • “Have traveled in 23 countries, and photographed the Taj Mahal to the fish & corals of the Great Barrier Reef”

Final thoughts

Lastly, quantifying your resume is an exercise to perform not only once you are looking for your next contract or job, but on an ongoing basis, so that you can leverage the metrics you have formulated for yourself in conversations and informal networking chats.

Good luck on your next application!

The Project Manager is not a Scrum Master

Written by Paul Oppong on . Posted in Articles. 3 Comments on The Project Manager is not a Scrum Master

A common question that arises is whether the Project Manager should be a Scrum Master.

Project Managers are sometimes expected to simply take up the role of Scrum Master when their organisation moves to taking an agile approach. This may well occur without the Project Manager being provided any training to take on this new, and quite distinct role. However, a recent survey by Scrum.org found that fewer than one third of organisations (31%) assign the role of Scrum Master to a Project Manager, and there are very good reasons for this. There are a wide variety of different people that could potentially take the role of Scrum Master, depending on the organisation, and it does not have to sit with the Project Manager role. Rather, the Scrum Master title should sit with the person who can do the best job of it. The following explains why the Project Manager is typically not a Scrum Master.

Different Skillsets and Activities

By the nature of the work that Project Managers and Scrum Masters do, the two are not particularly closely aligned, even if it seems at first glance that they are. Managing a project is not the same as being a Scrum Master. Scrum Masters have the role of mentoring, teaching, coaching and facilitating, while the role of the Project Manager is to ensure that the project runs to time and budget. This means that the Scrum Master relies on more of the so-called “soft skills” involved with helping people to move forward, while the Project Manager takes a more methodical, and arguably more of a “hard skills” approach. While both roles have an interest in ensuring a high level of team performance and driving efficiency within the team, the ways in which they go about this are very different. The Scrum Master facilitates and coaches, while the Project Manager assesses risk and manages issues and conflicts. 
Looking closer at what Project Managers and Scrum Masters do in terms of activities, differences can be seen here too. Project Managers manage projects, while the role of the Scrum Master is to is to make sure the rules of the Scrum are followed and that the Scrum Framework is adhered to. Project Managers work across all areas of the project spectrum, while Scrum Masters will largely only focus on the three areas of scope management, quality management and resource management. The Project Manager can commonly be responsible for a very large team, while Scrum Masters work within scrum teams which can be quite a lot smaller. Project Managers also plan regular project meetings as needed, but the Scrum Master will hold a meeting every day for the scrum. Even the emphasis of the work is different, since Project Managers schedule and plan, and narrow in on costs, while Scrum Masters are concerned with the value of the product. Importantly, Project Managers can serve in any industry, delivering projects. However, Scrum Masters only work in the IT industry, or similar related field. As can be seen therefore, there are both subtle and not-so-subtle differences between the skills and activities of Project Managers and Scrum Masters. 
Advertisement
[widget id=”custom_html-68″]

The Issue of Control

Ultimately, the Project Manager has a role that is focused on control. Project Managers are responsible for project costs, time spent, scope, quality of the end result, stakeholder management, risk and more. If the Project Manager is unsuccessful, they are accountable for this, and they will usually be blamed for issues. This means that the role of the Project Manager has to be based on control. This is achieved through each of the different stages of the project, such as its initiation, planning, design, running, monitoring, change control and even the final evaluation. On the other hand, the Scrum Master does not have an emphasis on control at all. Their role is ensuring everyone understands what their role is in the Scrum, getting rid of impediments, coaching people and ensuring that Scrum events occur. Importantly, they encourage the team to self-organise. This is not the same at all as the level of control that is involved with ensuring that project is managed effectively. 
As a Project Manager, being controlling is a good thing. It means that projects get delivered to time and to budget. But being controlling by nature is hard to change, and Scrum Masters are not controlling. It is very difficult for a person that is used to leading in a command and control style to adopt the very different, softer leadership style of the Scrum Master. 

What I still want my Project Manager to be the Scrum Master?

If, having considered the evidence above, you still believe that your Project Manager is the right person to be the Scrum Master, then there are some important steps you should take. You should review the experience they have working in the Scrum, and additionally provide some Scrum training. Perhaps most critical of all, you should determine if your Project Manager has energy, enthusiasm and interest for putting the Scrum in place. If they do not, then the initiative will be likely to fail, because any effective Scrum needs a great Scrum Master who is interested in and committed to making it work. The good news is, it is possible to learn how to be a great Scrum Master, but you must ensure that the passion to do so is there in the first place for this to succeed.

Summary

As has been seen, despite common misconceptions, the Project Manager is not the Scrum Master. The roles are different and require skillsets and activities that might be considered conflicting in nature. This is perhaps why less than a third of organisations assign the Project Manager to be Scrum Master. This is not to say that your Project Manager cannot be Scrum Master under any circumstances – they can – but the circumstances and level of interest have to be just right to get it to work.