Search results: "project management" Page 1 of 5

Going from Software QA to IT Project Management

Software QA

My journey in the world of IT began as a quality assurance analyst. For UPS, I would test and certify applications used in operations. I spent most of my time in the test lab with the rest of the lab rats. Testing software back then was the easy part, the hard part was building the right platform. Performing a ground up install of MS Windows Pro could take almost half a day and if it failed, you’d have to start over again. If you were lucky you got to use a ghost OS image, but even those presented their own challenges.
 
Later in my career I would go on to focus less on hardware and more on testing software. With Accenture I worked along side large testing teams on huge multi year waterfall software projects. We would create test plans consisting of hundreds of test scenarios. We then charged off to complete all the testing in a matter of weeks. Anyone who worked in QA (or dev) can attest to the agony of the waterfall project death march experience. Pressure from management, late nights in war rooms, and working weekends combined to make the QA role a nightmare.
 
Fast forward to the arrival of Agile and my role in QA became tolerable again. Instead of having a mountain of code dumped on me for testing, now I could test small chunks of software in two week sprints. The only problem was (and still is) that many organizations struggle building shippable software in sprints. This results in companies that are waterfall masked as Agile.
 
After almost a decade working in QA I decided I to get into project management. I always enjoyed connecting with people and I felt project management better fit my strengths. Through the guidance of mentors, lots of studying and hard work, I was able to become an associate project manager. After time I was able to work on larger projects, consulting for large companies.
 
Making the transition into project management was a great career choice for me. Project management much better aligns with who I am. For you it may be different. Your passion might be in QA and there’s nothing wrong with that.
 
If you are someone who works in QA and you’re considering get into project management, my advice is to go for it. Software QA analysts make great project managers because they are battle tested. I discussed this more in my last post “The identity crisis of the IT project manager“.
One thing’s for sure, if you’re not happy in your current role, don’t settle!

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master.

Follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.

Project Management – Why technical skill alone is not enough

Project Management – Why technical skill alone is not enough.

Project Management

Today’s changing business environment is becoming more and more complex. The global competitive economy is less predictable than ever. Organizations need project managers who have skills that support long-term strategy. For this reason, technical skills alone are not enough for project managers. PMI’s 2016 pulse of the profession report underscored this fact.

The report showed that business and leadership skills are in high demand. These skills, combined with technical skills, represent the PMI talent triangle (pic shown above). The ideal expertise areas are technical, leadership, and strategic and business management. “When organizations focus on all three skill sets, 40 percent more of their projects meet goals and original business intent.”

Companies should recognize the importance of business and leadership skills, and provide training. Many companies split roles to be either a “Business PM” or a “Technical PM”.  In my opinion this is a mistake. Instead of having two separate types of project managers, why not have just one that’s good in technology, business and leadership?

For new project managers, I suggest studying the three areas of the PMI talent triangle. Many good schools now offer flexible MBA programs with concentrations on leadership and strategy. I had the good fortune of going through the MBA program at Bethel University in St Paul Minnesota.  The program had a heavy concentration on leadership. As someone with a background in technology, the MBA helped me to become a better-rounded project manager.

For “technical” project managers like me, gaining business and leadership skills is crucial.  As the global economy continues to drive up complexity, the PMI talent triangle skills will be more in demand.

For more content like this, subscribe to the MacIsaac Consulting Blog.

To contact us about our services, click here.

 

How To Avoid Common Pitfalls of Business Analytics Projects

business analytics

We live in the early stages of a data analytics revolution. Data is driving the world and transforming the global economy. In a report published in December of 2016, McKinsey estimated that “45% of work activities could potentially be automated by today’s technologies and 80% of that is enabled by machine learning.”

While big data and AI investments are on the rise, many companies are struggling in their efforts to be data driven. A 2019 HBR article found in a study that “An eye-opening 77% of executives report that business adoption of Big Data/AI initiatives is a major challenge, up from 65% last year.”

To better understand business analytics and why companies are struggling, I recently attended an executive education course at the Carlson School of Management. The class covered a range of topics including artificial intelligence (AI), machine learning, big data. As a consultant who manages IT projects, I wanted to learn about what it takes to deliver analytics projects.

What Is Business Analytics?

Business analytics is an exploration of an organizations data, with emphasis on statistical analysis. It enables companies to make data driven decisions that help gain a competitive advantage. Companies that deliver business analytics projects treat data as a corporate asset. Below are the four main types of business analytics:

  • Descriptive Analytics – Descriptive analytics answers the question, what happened? It is an exploratory analysis that provides visualization and BI dashboards. This can help companies to use key performance indicators to understand the state of the business.
  • Predictive Analytics – Predictive analytics answers the question, what will happen next? It analyzes trend data to predict future outcomes. Data mining, machine learning, model lifting, and forecasting are techniques used.
  • Prescriptive Analytics – Prescriptive analytics uses past performance to generate recommendations for the future. Optimization, simulation and rules are used in prescriptive analytics.
  • Causal Analytics – Causal analytics answers the question, did x truly cause y? Before business decisions can be made based on analytics, you need a high degree of confidence. It’s not enough to go by gut feel, data trends or correlations. Casual provides the confidence using a/b testing, econometrics and experimentation.

Why Most Business Analytics Projects Fail

Gartner CIO research reports that more than 50% of analytics projects fail. Why do they fail? In short, most fail because companies neglect to connect the analytics to business value. They focus on analytics output, tools and technologies verses business outcomes. Some common pitfalls include not knowing what the problem is, force fitting a solution, or trying to boil the ocean. Poor data quality and a lack of technical expertise are also big issues.

Another reason business analytics project fail is due to the way they are managed. The traditional plan driven approach does not work for analytics projects. “Business analytics projects are often characterized by uncertain or changing requirements and a high implementation of risk. So, it takes a special breed of project manager to execute and deliver them.” (Viaene, Van Den Bunder, MIT Sloan Mgmt Review).

Setting Up Analytics Projects For Success

The best way to setup analytics projects for success is with framing. The goal of framing is to define the problem boundaries, break down the problem and determine the analytics method. This helps to reduce ambiguity and the risk of project failure.

There are different frameworks that can be used throughout an analytics project life cycle. Below is a description of a common framework that can help:

Situation, Complication, Key Question (S, C, KQ) – The S, C, KQ framework helps gather the information needed to provide a clear and holistic problem statement. The Situation provides the information relevant to the problem. It is the context that sets up the complication. The situation must lead to the complication. The two must connect.

The complication clarifies the need for change. It specifies why a change is needed and a decision must be made. The key question then follows from the situation and complication. It is the one focus of the project and it makes clear the decisions to be made. The key question should use the SMART guideline – Specific, measurable, action-oriented, relevant and time bound.

Below is a basic example of what the S, C, KQ framework might look like in a project definition sheet. The example provided is to solve a business problem for a health club:

The example gives provides a basic idea of the S, C, KQ framework. Once the problem statement is clear, the analytics project team can decide on which type of model to use. The final step in the framework process is to provide an outcome that is measurable and actionable. The outcome explains what business decisions will be made based on the results of the analysis. The outcome also explains how success will be measured.

With a solid framework in place, a cross-functional analytics team can then develop a model. A typical deliverable from an analytics project team might include a web dashboard that provides predictive or prescriptive analytics. Data engineers and data scientists write algorithms and build the models. They also perform data cleansing, aggregation, integration and transformation.

Summary

Companies need to treat their data as a corporate asset. The ability to use data to predict future performance provides a competitive advantage. While business analytics is growing in importance, many companies are failing in their efforts to become data driven.

A key to success with business analytics projects is to use a framework that will align the analytics with business value. Analytics projects must be managed in an agile way that adapts to changing requirements. An iterative and experimental approach to project delivery is best.

Often the biggest roadblock to business analytics success is the business imagination. Companies must find ways for human intelligence and machine intelligence to work together. 

A special thanks goes out to the Carlson Executive Education program and professors Ravi Bapna, Gedas Adomavicius, Ellen Trader, and De Liu. Below is a picture of our business analytics class filled with business leaders from the Twin Cities.

About the Author: Mike MacIsaac is the founder and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master/Coach. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

Identity and Access Management (IAM) Is More Important Than Ever

It’s a company’s worst nightmare. A data breach or cyber-attack. Cyber-attacks continue to be a growing threat, but not all data breaches are caused by outside hackers. Ask Morgan Stanley. In 2015, the financial services firm revealed that an employee had stolen data from more than 350,000 accounts. Forrester estimates that 80% of data breaches have a connection to compromised privileged credentials, such as passwords, tokens, keys, and certificates.

To avoid a data breach nightmare, company’s must ensure only the right people can access appropriate systems, data, and resources, for the right reasons. This is accomplished through Identity and access management (IAM). IAM is a specialty discipline within cyber-security. It helps companies increase productivity while securely enabling access to applications and systems.

IAM has to be an essential part of your IT toolkit. The typical business user has dozens (even hundreds) of applications they must access to do their jobs. These applications span cloud, mobile and on-premise solutions, and all can hold confidential, sensitive and regulated information.

To address the access management problem, there are many different IAM products on the market. I’m currently finishing a project to put SailPoint IIQ in place for a large financial institution. SailPoint is a Java based web application that integrates with legacy systems and Active Directory (AD) enabled applications. Auto-provisioning, native change detection, reporting and access certifications are some of the features SailPoint IIQ offers. Some of the other popular IAM products include Oracle Identity Management (OIM), Microsoft Identity Manager and Microsoft Azure Active Directory.

Regardless of the product you choose, having the right IAM strategy in place is key. The implementation of IAM can be very challenging. It takes strong collaboration between business, IT and operational teams. It also takes prioritization from leadership. Without executive sponsorship, business system owners and stakeholders may be reluctant to assist.

If you are in early stages of IAM or if you are already into delivery, MacIsaac Consulting can help. We provide services to help you put the right IAM strategy in place and we provide delivery resources.

Below are pictures of the cross-functional IAM team in action from my current project which is winding down. The work is very challenging, as most IAM projects are. Yet, the project will be successful because the client made IAM a top priority. They made the investment and provided the support to get the job done. That’s what it takes.

If your company is ready to deliver IAM, or if you need help on your current journey, let’s talk!

We used a Kanban board to track each Application going through the IAM integration process
Cross-functional team made up of IAM engineers and business members
Expert SailPoint IAM engineers working hard in the team War Room

About the Author: Mike MacIsaac is the founder and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master/Coach. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

Why Middle Management Is The Ultimate Agility Killer

“So much of what we call management consists in making it difficult for people to work.” – Peter Drucker

For the past seven months I have been managing a difficult IT project for a large organization. The experience has me convinced that middle management is the ultimate roadblock to agility. I get why they call it the frozen middle. To understand the root of the problem, you must look beyond managers themselves. The core of the issue lies within organizational structure and culture.

While many companies are undergoing agile transformations, most still use old organizational models. The matrix structure is a top offender. Loaded with hierarchy, bureaucracy and management layers, it is anything but agile. If an agile team were superman, the matrix organization would be kryptonite.

Below are some of the ways the matrix organization impedes agility:

Disjointed Functional Areas

The matrix organization splits functional areas into groups. In IT for example, developers belong to one group, QA analyst to another, and so on. The employees within the group’s report to a manager. The manager then places employees on projects within the company.

Here’s the problem. Functional groups are setup to be in conflict against each other. I can’t tell you how many times I’ve seen functional areas point blame at each other when challenges arise. “It’s development’s fault”, or ” its QA’s fault”. Instead of promoting an attitude of one team, the matrix environment sets the stage for political strife. Managers snipe at one another as they fight to stand their ground.

The result of all the political warfare is hindered project teams. Team members just want to accomplish their work. Instead they get harassed by managers who need ammo to defend their functional area.

The Value-Add Dilemma for Functional Managers

IT functional managers working in a matrix environment have a dilemma. They usually come from a background of product delivery, where their contributions were clear to see. When they leave the trenches of project work to become managers, they realize their new role is about staffing. How then are they to prove their value if they are not delivering work? They attempt this in two ways.

First, they involve themselves into areas where they aren’t needed. As a project manager and Scrum Master, I have had to ask functional managers to not attend project team meetings. In teams, the presence of non-core members causes disruption. Teams operate at peak performance when each member of the team knows and trusts each other. The moment you introduce someone who is not part of a team, especially a ‘manager’, everyone clams up. The team reverts to the ‘forming’ stage of Bruce Tuckman’s four stage team building model.

Second, functional managers try to prove their worth by raising ‘concerns’ to leadership. Since they are on the sidelines for projects, voicing concerns about potential issues gives them an outlet for exposure. It’s a way for them to say, hey I think there is an issue, see how I’m adding value? Unfortunately, this often results in a lot of noise and distractions. While their intentions may be good, they end up stirring the pot.

These behaviors are not the fault of the managers themselves. They are usually good people with strong backgrounds. The problem is not the people. The problem is the functional management role itself. It doesn’t give people a way to add value.

Forming teams around projects

The matrix organization forms teams around projects. It’s not uncommon for people to be on two, three or even four projects at a time. This results in switching costs, the cost of doing more than one complex task as a time. Studies show that when people switch their thinking to different topics, their productivity goes down.

Poor team development is another result of forming teams around projects. Assigning employees to new projects doesn’t allow enough time for team development. It takes people working together for a while before a high performing team emerges. The moment you assemble a new team for a project, the team building process starts from scratch.

PMO’s

When it comes to process overload, the PMO (Project Management Office) is the worst. PMO’s force organizations to follow rigid standards, processes and tools. Many are trying to adapt to agile practices, but the results are the same. Too much process and bureaucracy. It goes against the first principle outlined in the popular Agile manifesto. Individuals and interactions are valued more than processes and tools.

While processes and controls are necessary for organizations, too much is an agility killer. Forcing project teams to create wasteful documentation is a common problem. I once had a manager ask that a large test plan be created for each Agile two-week sprint. The result was a QA analyst spending more time working on a test plan than collaborating with the team. To achieve agility, you must value working software more than documentation.

The Solutions to the Middle Management Conundrum

The best way to combat these issues is by forming stable, cross functional, capability teams. True agile teams. The teams can use whatever framework, processes or tools that work best for them. They don’t have to follow arbitrary processes from a PMO.

There are many benefits to the stable product delivery teams’ model. It eliminates the need for excessive management by doing away with functional groups. This puts emphasis on product delivery and providing value to the customer. It also reduces the internal politics that the matrix organization creates.

By keeping teams intact, it allows enough time for team development. Instead of forming teams around projects, project work goes through teams. This is a mindset shift away from traditional project management to modern product delivery.

Agile teams report up through one line of management. Managers are responsible for strategy and ownership of their capability. This gives managers clear roles and responsibilities that provide value. They engage in product delivery.

Part of the goal with the product team model is to create a flatter organization and to adopt an agile culture. While these changes are hard for large organizations, many companies are having success. In Minneapolis, where I live, companies like Best Buy, Target, United Health Group, and TCF Bank are making significant progress. They understand that the balanced matrix organization is no longer adequate to stay competitive.

Organizations still using the balanced matrix structure need to change. Implementing a stable product team model improves agility and benefits the customer. It also provides a more enjoyable work environment for managers and employees.

About the Author: Mike MacIsaac is the principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. You can follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

3 Things You Can Count On The Best Project Managers To Do

Leadership

I’ve always had a great deal of respect for project managers. Managing projects, especially IT projects, is challenging. It requires skilled individuals who are strong communicators and cool under pressure. They juggle competing priorities while managing personality conflicts and keeping stakeholders happy.

I’ve been fortunate enough to have worked with some great project managers. Over time I’ve learned there are three things you can count on them to do. Here they are:

1.   They provide clear communication – They keep stakeholders updated through easy to understand written and verbal communication. A lot of project managers struggle in this area, and for good reason. It’s difficult to provide an easy to understand update when managing complex projects. The tendency for project managers is to rush and write up a long email that gets down into the weeds. They think they’re doing a good job because they provided a lot of information. In fact, they leave people confused and frustrated. People don’t want to read a long email and figure out what it means.

2.   They take full ownership and drive the work – Projects are challenging and messy. If they weren’t, there wouldn’t be a need for project managers. Great project managers take stress of their bosses’ plate by taking full ownership. They will drive the project to completion. Yes, sometimes project managers will need help from leadership. When those times come, it’s important they ask for help. But most of the time, great project managers do whatever it takes to lead the project to success.

3.   They stay positive – If the project manager starts to get down and negative, the whole team will follow. It’s so important as a project manager to stay positive, even when the going gets tough. And, it will get tough. I’ve yet to experience any IT project that didn’t come with some level of stress or issues. Problems will come, but the project manager needs to stay positive. This is the essence of leadership. Collin Powell once provided a great lesson he learned on this from infantry school. They taught him: “no matter how cold it is, lieutenant, you must never look cold. No matter how hungry you all are, lieutenant, you must never appear hungry. No matter how terrified you are, lieutenant, you must never look terrified. Because if you are scared, tried, hungry and cold….they will be scared, tired, hungry and cold.”

Summary

Project management is difficult. If it wasn’t, there wouldn’t be such a large demand for project managers. If you are a project manager and you want to stand out from the crowd, focus on these three things. First, take the time to provide clear written and verbal communication. Second, take full responsibility to drive the project. Lastly, be positive, especially when things get tough.

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an Agile Delivery Consultant and IT Project/Program Manager. Follow Mike on Twitter@MikeMacIsaac or visit Mike’s blog.

Hands Down, This is The Best Skill To Have As a Project Manager

Best Skill To Have As a Project Manager

If you are considering a career in project management, listen up. There are a lot of different skills needed to be successful, ranging from people management to organization and planning. There is one skill though, that you need above all the rest.

The hands down best skill to have as a project manager is the ability to communicate.

Project managers can spend up to 90% of their time communicating. Webster defines communication as “a process by which information is exchanged between individuals through a common system of symbols, signs, or behavior”.

The communication process requires both a sender and receiver. The sender transmits the message to the receiver. The receiver then decodes and acknowledges the message. The below image from PMI’s PMBOK is a good outline of the communication process.

Most project managers focus on the sending part of communication, overlooking receiving. This is understandable because project managers must send messages often. The receiving part of communication though, is as crucial.

Let’s look at the different aspects of communication for project managers. I have broken them down into speaking and writing (sending), and listening (receiving).

Speaking

You don’t have to be an amazing orator to speak as a project manager. You also don’t have to be an extrovert who enjoys being the life of the party. I’m an introvert who’s not always comfortable speaking in groups. This is an area which I’m sure I could improve, but my discomfort in speaking is not always a liability. When I’m not speaking, I’m listening, or at least trying to.

The four important areas of speaking in project management are the following:

  • Running meetings
  • One on one communication with team members or stakeholders
  • Proving updates to leadership
  • Giving presentations

I could write a full post about each one of the speaking topics, because they are all important. I enjoy one on one communication the most. Effective one on one communication requires emotional and social intelligence.

If you have trouble speaking, I recommend taking a Dale Carnegie course on speaking. Warren Buffet credits a Dale Carnegie course to helping him overcome his fear of speaking.

Writing

Good clear writing is crucial in project management. One could make the argument that writing is the most important skill of all. The project manager must write by sending emails, status updates, meeting minutes, action items, project plans, etc.

The challenge for the project manager is to communicate clear through their writing. This is no easy task giving the complexities of projects, and the amount of ambiguity that exists in corporate communication. Most companies have their own unique language. The language consists of acronyms and jargon, which makes clear writing more difficult.

Project managers can fall into the trap of using ambiguous corporate jargon in their writing. Part of this is because of fear and corporate politics. What if I write the wrong thing, sound stupid, or make an enemy? A good project manager will put those fears aside and take the time to write good clear English. You can write clear while also being smart about corporate politics.

As a program manager, part of the reason I blog and write LinkedIn posts often, aside from the fact that I enjoy it, is to work on improving my writing. I know I am not a great writer, so I must continue to work at it. Writing, like any other skill, requires continual practice.

Remember, it’s easy to write something confusing, but it takes time to write something clear. For a great resource on writing, I recommend William Zinsser’s classic book, “On Writing Well“.

Listening

Communication in project management is not only about talking or writing, it’s also about listening. I can’t emphasize enough the importance of listening.

To better understand the importance of listening, I’ll paint a picture. Imagine a sea-captain leading a heroic voyage across the Atlantic in the late 1700s (I’m on a revolutionary war kick now, stick with me). For the voyage to be successful, the captain doesn’t tell the crew what to do, all the time. Instead, the captain spends a good part of his time listening to the crew. The captain receives all the messages on problems, concerns, and suggestions from the crew. After receiving the messages, the captain can then take the appropriate actions.

The project manager is like that of a sea-captain. He or she needs to listen to the team members and stakeholders. If the project manager is not listening, the project will most likely go off course.

For a good resource on listening, I recommend Stephen Covey’s book, “The 7 Habits of Highly Effective People“. In this great book, the 5th habit is “Seek First to Understand, Then to Be Understood”. Covey explains how to use empathy, a part of emotional intelligence, to achieve the highest form of listening. Emphatic listening goes beyond active listening, to understand how someone feels.

Summary

I’ve only begun to scratch the surface on the importance of communication in project management. I haven’t touched on communication channels or nonverbal body language, which are also important.

If you are new or considering a career in project management, I hope this post has been helpful. The good news is that we can all continue to improve our communication skills.

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. Follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog.

 

 

Managing Project Risk Should Be Top Priority

Managing project risk might be the most important responsibility in project management. Risk management is often overlooked. Usually people think about things like communication, organization, and interpersonal skills as key aspects of project management. While these are important, if I had to pick one critical skill for project management, I’d have to say managing project risk. Every project comes with risks and if you don’t plan for them, you’ll spend all your time putting out fires. To manage project risk, you must be proactive, not reactive. I’ve found that the best project managers are always looking out for risks and they have a natural sense for identifying them.

Managing Project Risk

Project risk is defined by PMI as, “an uncertain event or condition that, if it occurs, has a positive or negative effect on a project’s objectives.” Risks are the unknowns, and a good project manager is like a lookout person for a ship, scanning for risks. They are using their binoculars to see any trouble in the waters ahead.  Not only are they on the lookout for trouble, but they also are planning to deal with it.

At the beginning of a project, and all throughout the project, it’s the job of the project manager to identify and manage risks. This is done through analysis and talking to key stakeholders and team members on the project. The project manager needs to question everyone and ask for risks that others know about.

The project manager then needs to access the likelihood and risks to address. After determining what risks to address, the project manager needs to determine what action to take for the risks.  Part of the mitigation plan usually involves setting aside some contingency funds for risks.

Ask yourself and your project management team, are you doing a good job of managing project risk? Project managers should devote a good portion of their time to managing project risk.

 

About the Author: Mike MacIsaac is the owner and principal consultant forMacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. You can follow Mike on Twitter@MikeMacIsaac or subscribe to Mike’s blog

 

12 Ways Management Can Empower Teams And Create Agility

empower teams

Mike MacIsaac – President at MacIsaac Consulting Inc

With the advance of technology and globalization, organizations today must have agility. It doesn’t matter the industry, companies need to be able to adapt to change. As a consultant, I’ve seen this need first hand throughout the tech, retail, and financial industries.

Gone are the days when different departments within a company worked in silos. Companies who still do this, and use a static organization structure, will struggle to survive. They will fall to the competitive advantage of the agile organization.

The problems faced by companies today are too complex to not be agile.  The pressure put on from external forces demand a new way of thinking and collaborating.

One way to create agility is through the use of decentralized cross-functional teams (CFTs).  A CFT is a team made up of people from different functional areas within the company. These experts work together to achieve a common goal. Over time the team develops synergy, and becomes high performing. Team synergy vastly exceeds the productivity of individual efforts.

When management empowers CFTs to make decisions and self-organize, the teams move fast, really fast. Team autonomy and empowerment promotes an atmosphere of trust, creativity, and worker satisfaction.

One of the greatest benefits of empowered CFTs is their ability to manage chaos. This phenomenon is counter intuitive to our natural reaction to manage chaos. Most of what we learn in business school aligns with the carrot and stick style of management. The more things get out of control, the more we tighten up our grip on the team. As managers, we have to let go of this notion of command and control. We can empower teams while still holding them accountable.

In a recent HBR article, Michael Mankins and Eric Garton describe how Spotify balances employee autonomy and accountability. They write “Companies that take the approach of empowering autonomous teams must find ways to ensure that coordination and connectivity happen among those teams without relying on controlling managers. Again, it’s a matter of managerial art as well as science to achieve alignment without excessive control.”

If you assemble a CFT with people new to such an environment, there will be a learning curve. You can’t expect people to self-organize and make decisions when they are used to being controlled.  The key is for CFTs and management to learn a new way of thinking, but this takes time.

Ken Schwaber, who formed the Agile Scrum framework along with Jeff Sutherland, writes “A team requires concrete experience before it can truly understand how to manage itself and take the responsibility and authority for planning and conducting its own activities.”

Below are 12 principles that can help management develop high performing cross-functional teams:

  1. Create stable cross-functional teams – Creating stable CFTs, dedicated to long-term goals, is necessary for high performance, quality and innovation. To do this you must dedicate resources and provide constant training. Each team member must have knowledge and expertise in a certain functional area. Changing team resources and not allocating for long-term planning is a killer to team performance.
  2. Provide a clear and compelling purpose – People suffer when they lack purpose. It is the responsibility of management to provide a purpose. People need a purpose because it creates intrinsic motivation. If employees are assigned tasks that have no meaning to them, they will lack motivation. Management should communicate how the goals of the team align with the long-term goals of the company.
  3. Protect the teams – Run interference and protect CFTs from distractions and skeptics. Management must be committed to the overall purpose of the organization and the CFT. There are always skeptics and people who are resistant to change. It is well advised for management to not include these types on change efforts and new CFTs. Skeptics will cause more harm than good. Staff CFTs with people with positive attitudes who will champion the goals of the team and organization.
  4. Give teams the help they ask for – With the high performing CFT model, managers don’t tell the team how to do their job. Instead, the teams tell management what they need to be successful. It is the job of management to listen to these requests and do their best to provide the teams with the help they ask for. Again, just because management is not telling teams what to do, it doesn’t mean they shouldn’t hold teams accountable.
  5. Empower teams to make decisions – Management can hold teams accountable for results, but they need to empower teams to make decisions. The decentralization of authority allows teams and organizations to produce results fast while responding to change. Management is still responsible for telling teams what needs to be done, but the teams are responsible for how it will be done.
  6. Allow mistakes to be made – Encourage teams to accomplish stretch goals, but do not punish if everything is not achieved. It’s important for management to help drive out fear. When employees are afraid of being punished for mistakes, it kills innovation. The important thing is learning from mistakes. Teams should continually take inventory on how they can improve.
  7. Use information radiators – On CFTs, everyone needs to see what’s going on and what needs to be done. Having a board that displays visual controls enables and promotes teams to self-direct. Information radiators also let management and outside stakeholders view how the team is doing and how much work is in progress.
  8. Deliver as fast as possible – Fast product delivery results in increased business flexibility and happy customers. Short value streams eliminate waste and they allow decisions to be delayed. Management should promote the idea of delivering valuable products fast. Often time’s people think that you can’t deliver fast without compromising quality. This is not the case when you build quality and integrity into product development. The fast delivery system does not compromise on quality; in fact it improves quality because consumers get the product faster. This enables consumers to provide feedback sooner which can go back into the design of the product, improving quality.
  9. Analyze and improve throughput – The best way to optimize an organization is to focus on throughput. The theory of constraints teaches us to find bottlenecks in the system and fix them. Teams should continue analyzing the system, identifying bottlenecks, and removing them. When teams focus on improving non bottleneck areas of the system, it doesn’t help improve throughput. Following the theory of constraints principle, teams can delivery fast.
  10. Promote quality built into products – In Edward Deming’s book “Out of the Crisis” he writes “Quality comes not from inspection but from improvement of the production process. Inspection, scrap, downgrading and rework are not corrective action on the process”. This means for software development, we need to get away from this notion that QA is this separate process that happens after software development. We should not be inspecting quality into the software through QA. Instead, QA should be happening as part of software development through the use of test driven development and automation. This enables quality to be built up front, instead of through inspection.
  11. Improve quality by learning from the consumer – In the Agile software development “Scrum” we do product reviews continually with the consumer. This same principle can be implemented throughout the organization. The goal is to feed the consumer reactions and feedback back into the design of the product to improve quality.
  12. Provide servant leadership – In Scrum, the Scrum Master acts a servant leader. The Scrum Master job is to remove impediments and help the team. This servant leadership practice is a great example for management to emulate. By supporting and helping teams, you foster at atmosphere of empowerment and trust.

For many organizations, the points I listed may be a significant change from their current reality. It’s not easy to put in place all these changes. Even for the modern agile company, agility is an ongoing learning process. If your organization needs guidance, at MacIsaac Consulting we are here to help. From advising leadership, to providing resources, we can guide you on your agile transformation journey.

About the Author: Mike MacIsaac is the president and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. Follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.

References

Deming, E. (1982). Out Of The Crisis. Cambridge, MA: MIT.

Mankins, M & Garton, E (2017). How Spotify Balances Employee Autonomy And Accountability. https://hbr.org/2017/02/how-spotify-balances-employee-autonomy-and-accountability

Poppendieck, M. (2003). Lean Software Development. Upper Saddle River, NJ: Pearson Education.

Schwaber, K. (2004). Agile Project Management With Scrum. Redmond, WA: Microsoft Press.

 

Difficult project stakeholders? Here are 5 ways to deal with them

5 ways to deal with difficult project stakeholders

Difficult Project Stakeholders

Project managers have an ethical responsibility to keep their project stakeholders informed. How much to keep stakeholder informed, and satisfied, depends on the level of power and interest of the stakeholder.

If you’ve ever managed projects, odds are you had to deal with a difficult stakeholder at some point. You know who I’m talking about, people who throw grenades at you and your project every chance they get. They might make last-minute scope change requests, send rude emails, or be confrontational in meetings. The list of possible difficult behaviors is huge.

They could naturally be a difficult person, of they may have it out for you and your project.

If you don’t know how to deal with a difficult project stakeholder, you could be in for a nightmare situation. Sometimes you need to use an unconventional approach.

Here are 5 ways to deal with difficult project stakeholders:

  1. The “olive branch” –  Go out of your way to engage with them early in the project. This is the diplomatic approach. Due your best to include them in the everything. Provide transparency. If they are showing signs of being difficult, acknowledge any concerns they have. Do your best to develop a positive working relationship. At this point, you are going on the offense to diffuse them. This is always my initial approach.
  2. The “keep em in the dark” – If you’ve done step 1 and it’s to no avail, it’s time to change the approach. If diplomacy isn’t working, it’s time to get tough and strategic. Nobody should let someone cause problems for their project. Managing projects are difficult enough, we don’t need people making it worse. The keep em in the dark approach means involving the difficult stakeholder as little as possible. Try to go around them and not let them do too much damage. John Kotter says the best way to deal with a change resister is to go around them. If the stakeholder has a high level of power, and interest in the project, unfortuntaely this approach is not an option.
  3. The “let’s do this!” – The “let’s do this!” means it’s time to drop the gloves and battle. Stick up for yourself and your project. Push back! Sometimes it can be effective when you tackle the problem head on. Don’t be afraid to disagree and meet with the difficult stakeholder one on one to give them a piece of your mind. Who knows, it could be they didn’t realize they were causing you problems.
  4. The “sound the alarm” – When all else fails, it’s time to escalate. Escalating to management about a difficult resource is a last resort. I try to avoid doing this at all cost. What your telling your manager is that a person is giving you a problem, and you can’t handle it. Now it’s your managers problem. Your manager can then decide if they want to take action and either speak to the stakeholder, or to their boss.
  5. The “okie-doke” – The okie-doke means keeping the difficult stakeholder involved to keep them happy, but don’t involve them in key decisions. Make them feel like they’re a part of the project, when in fact they’re not. You’re pulling the wool over their eyes. Manipulation is certainly not a preferred approach, but if all else fails….

Dealing with difficult project stakeholders is part of the job in project management. The steps I listed above can be helpful but only you can decide what approach to use. It depends on the level of power and interest of the stakeholder. If your sponsor is a difficult project stakeholder for example, you would never keep them in the dark.

How do you deal with difficult project stakeholders?

 

About the Author: Mike MacIsaac is the owner and principal consultant for MacIsaac Consulting. Mike provides leadership as an IT Project and Program Manager as well as an Agile Scrum Master. Follow Mike on Twitter @MikeMacIsaac or subscribe to Mike’s blog.

 

Page 1 of 5

Powered by WordPress & Theme by Anders Norén