Search results: "project management" Page 2 of 5

Communicating as a project manager – Don’t sugar coat it!

businessman drawing a line from point A to point B (selective focus)

This morning I attended a PMI Minnesota chapter breakfast. The presenter, Gus Broman, spoke about the importance of communication in project management. Gus gave a good talk and as usual with PMI events, there was good discussion among the attendees.

Although it wasn’t a big focus of Gus’s talk, one point he mentioned was being direct. After he mentioned this, I dwelled on how important it has been for me as a project manager to be direct. The tendency for new project managers, and I’ve been guilty of this, is to not be direct.

We sugar coat it when problems arise, or we delay giving bad news. We do this for many reasons. We want to be nice. We don’t want to deliver bad news. We want people to like us, etc.

The problem is, the more you delay or sugar coat bad news, the more you hurt your project. None of us like delivering uncomfortable news, but we have an ethical obligation to be direct.

Project management is all about communication, and it’s important to be clear and concise. Good communication is about not leaving any room for misinterpretation. As a project manager, you need to manage down and up, and your communication needs to be crystal clear.

The longer I work as a project manager, the more clear it becomes to me that I have to be direct. Being direct and candid with your team members and leadership gets everyone on the same page.

So be professional and tactful, but be direct. Don’t worry about hurting feelings, they’ll get over it.

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

To contact us about our services, click here.

 

 

 

The art of being an Agile project manager

Agile Project Manager

The Agile project manager role has become quite common. As more organizations adopt Agile, the traditional project manager role has morphed into a hybrid Scrum Master. For those of us working as Agile project managers, we have the challenge of blending two different, even opposing, roles into one. It begs us to question, can one even be an Agile project manager? Ken Schwaber seems to think so. The co-founder of Scrum wrote a book called “Agile project management with Scrum”.

Let’s back up and take a look at the differences between a Scrum Master and a project manager.

  • The Project Manager – If you have your PMP, you know that project management is all about planning, control, and communication. The traditional project manager role is big on command and control. The PM has authority over the team. The PM manages the team, assigns work, and is accountable for the success of the project. The PM is responsible to create a detailed Gantt chart project schedule and all planning happens at the start of the project.
  • The Scrum Master – If you have your CSM, you know that a Scrum Master is not a project manager. Whereas the project manager is about command and control, the Scrum Master is about servant leadership. The Scrum Master does not have authority over the team, he is more of a guide and coach. The Scrum Master shields the team from interference’s. He removes impediments, and ensures Scrum the team understands processes and values.

Knowing the differences between the two roles, we can now see how working as an “Agile Project Manager” is an art form.

Below are some tips to help you be an effective Agile project manager:

  1. Let go of the idea that Agile or traditional project management has to be one way, all or nothing. Organizations are complex and tackling a change like Agile adoption is difficult. This is especially true for large organizations used to rigid structure and control.
  2. Don’t be afraid to switch hats, between PM and Scrum Master, when necessary. For example, I try to empower the team and not tell people what to do (with my Scrum Master hat on). Yet, when the team starts running into trouble, I create a sense of urgency and give direction (putting my PM hat on).
  3. Help to educate the leadership team on the difference’s between Agile and Waterfall. The real value in Agile is in the core values, not the practices. In fact, most Agile projects that fail are a result of company culture not aligning with Agile core values.
  4. Make the Agile ceremonies mandatory. Agile teams may be self empowered, but you have to at least follow the key ceremonies. If you’re not having daily standups, sprint reviews and retrospectives, don’t call yourself Agile. These Agile practices are low hanging fruit. They are the easiest things for teams to adopt. The hard stuff is getting the core principles right.
  5. Perform the Agile PM role to the best of your ability, and do it with a smile. Whether you are an employee or a consultant, your job is to fulfill the need of the organization. Try to improve processes, but as Dale Carnegie says “don’t criticize, condemn, or complain”.

The art of being an Agile project manager means being flexible and willing to lead. It means accepting that some roles won’t always be by the book.  It means understanding the value in both the Scrum Master and PM roles, and finding a way to make them work together.

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

To contact us about our services, click here.

 

 

 

 

 

 

Leading cause of failed Agile projects? Company culture not aligned with core Agile values

In the 2015 VersionOne state of Agile survey, the top reason for failed Agile projects (46% of respondents) was company culture being at odds with core Agile values.

fail_at_strategy

I’ve experienced this myself. Companies understand they need to get better at delivering software, so they decide to assemble Agile teams and bring in training.

The Agile teams use all the Agile practices, yet leadership sees little improvement. Why is there little improvement? Usually it’s because the company has a philosophy and culture that are at odds with core Agile values.

Below are the core values outlined in the Agile manifesto:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Organizations have to have the ability to adapt to change. The advance of technology and globalization have made this an absolute need to stay competitive.

Adopting Agile is not just about improving how a small project team delivers software. It’s bigger than that. Leadership has to get on board with Agile values and principles. Organizations of the future will be dynamic,  fluid, and need leadership at all levels. The days of a static hierarchy org structure will soon be long gone.

The question remains, what should leadership do to align the company culture with Agile core values? My advice is to not try and change the culture head on. Many have tried and failed. Instead, allow the Agile team(s) to adapt their own rules and culture. Think of them as an organization within an organization. Allow them exceptions to old buerecratic processes. Help them remove any impediments that’s slowing them down. Let them develop their own mini culture.

Once you do this and start seeing success, you can then begin to expand out the new culture. The idea is to start changing the company culture in small chunks, one area at a time.

For large organizations, changing company culture is a monumental challenge. You need leadership at the top to champion the change. You’ll need buy in and a sense of urgency.

Once Agile core values align with company culture, product delivery will go faster and changing priorities will be managed better.

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

To contact us about our services, click here.

 

 

 

 

The Truth About the Limitation of Scrum

limitation of scrum

There is something I’d like to get off my chest. There is this notion in Agile that project management is no longer needed. Some even think that the role of a project manager will soon be extinct. Before we chase away project managers with pitch forks, lets back up a bit. I’m 100% on board with Agile and with Scrum, but I disagree that the need for project management is going away. The reason is that Scrum has a limitation. It is not designed to deliver large scale projects, at least not without help. The complexities of large scale projects demand the need for project management. This may change at some point, but I don’t see it happening any time soon. And, I’m not sure it should.

I can envision the Agile purists as they read this. Project managers needed in Agile? Scrum has limitations? Blasphemy! Hear me out.

When I refer to large scale projects, I mean projects that could have anywhere between 5-30 changed systems. These types of projects usually include complex system dependencies and a lot of coordination. The systems need to integrate and plan their production releases based on their dependencies. Someone needs to oversee that it comes together, and that someone is a project manager.

On Scrum teams, no, there is no need for a project manager. There are only three defined team roles in Scrum. They are Product Owner, Scrum Master, and the Development Team. Scrum is perfect for teams that focus only on one product or component. As an example, a Scrum team may focus on the search feature of a website.

The need for a project manager shows itself when you have large-scale initiatives. When you have a large project that impacts many Scrum teams, someone must coordinate all the dependencies between the teams. Without a project manager, who will do this? I posed this question in a recent advanced Scrum training course. I then proceeded to watch the instructor twist into a pretzel struggling to answer it. I was then referred to a course offered on Scrum@Scale.

Scrum@Scale, along with LeSS, and SAFe are the popular scaled Agile frameworks. While each of these have their benefits, they also have limitations when it comes to large scale projects. The problem is not scaling more Scrum teams, although that poses a different set of challenges. The problem is managing large scale projects.

In a recent HBR article, Agile at Scale, Jeff Sutherland and other experts discussed large scale Agile projects. They said you can establish a “team of teams” (or Scrum of Scrums), and issues that can’t be resolved can be escalated up to leaders. I’m all for that, but it still doesn’t answer the question of who is coordinating the work of all the teams? They go on in the article to reference Saab’s aeronautics business. “Aeronautics also coordinates its teams through a common rhythm of three-week sprints, a project master plan that is treated as a living document”.

I found it interesting that they referenced a company that uses a project plan in an article on scaled Scrum. This further indicates to me that we need to pause on the idea of abandoning project management.

Scrum@Scale is the model Jeff Sutherland advocates for scaling. In Scrum@Scale, there is a Chief Product Owner (CPO) and a Scrum of Scrums Master (SoSM). They are like the team level Scrum Master or Product Owner roles, but at scale. These roles sound like they will help address the challenge of managing large-scale projects, but there is still a gap. While a SoSM focuses on removing impediments and the CPO on prioritization, you still need someone to look at the project from a holistic view. Someone must coordinate team dependencies, not to mention manage risk, schedule and budget. In short, you need a project manager.

The need for project managers on large scale Agile projects has fueled the rise of SAFe. If you’ve read my post on the problem with SAFe, you know that I’m not a huge fan. But, at least SAFe acknowledges that someone needs to coordinate the work of self-organizing teams on large scale projects. They refer to the role as a Release Train Engineer (RTE), but it sounds a lot like a project manager to me.

Why do Agilest cringe when they hear the words project manager, or for that matter, the word project? When I say there is a need for project management in Agile, I am not saying that projects need to move in sequence from phase to phase like waterfall. I’m not referring to a command and control tyrant who manages Gantt charts with an iron first. Project managers today can lead large initiatives and still follow Agile principles. Projects can still use an iterative experimental process.

You may argue that by creating an architecture where each Scrum team works on an autonomous application, you end the need for a project manager. Spotify is a good example. Lightweight autonomous applications are the way to go, but you still can’t get away from dependencies on large scale projects. In most large fortune 500 organizations, legacy applications are dependent on other systems.

In summary, Scrum has a limitation when it comes to large scale projects. Project managers are not needed on Scrum teams, but they are still needed in Agile for large scale projects. What is changing is not that the Project manager role is going away. It is the role itself that is changing to align with Agile values and principles. The Scrum organizations seem to be working hard to address this limitation through their scaled frameworks, but they have a long way to go.

If you have experienced large scale Agile projects where there was no need for a project manager, I would love to hear about it. I’ve worked for many organizations that have adopted Agile and I’ve yet to come across one that had no need for project management.

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 subscribe to Mike’s blog.

Digital Disruption Has Exposed a Need For Soft Skills

empower teams

The PMI (Project Management Institute) released their 2018 Pulse of the Profession report. The report gives good insight into the current state of global project management.

What I found most interesting was the effect of disruption on project management. We are in the midst of digital disruption affecting almost all industries. A good part of manual work has already been replaced by automation. AI, Big Data, Data Intelligence, and Healthcare reforms are a few of the disruptive trends already affecting businesses.

Dr. Michael Chui, a partner at McKinsey Global Institute, said that knowledge of these disruptions is crucial for project managers. It’s important to “understand the art of the possible and try to stay at least abreast, if not ahead, of what these technologies can do.”

Project management is no longer only about managing scope, schedule and budget. Project managers need much more than technical skills. They must be able to lead strategic initiatives that drive change in organizations.

Dealing with digital disruption, leadership skills and business acumen are critical skills. Organizations would be well advised to invest in training to help their project managers build upon these skills. In PMI’s survey, 51% of respondents reported that soft skills are much more important today than they were just 5 years ago.

It’s ironic, the more digital the world becomes, the more the need for basic human skills increases. Emotional and social intelligence are critical assets for project managers. I recognized this growing need for soft skills in project management, years ago. The need goes beyond project management. In information technology, there is a drought of emotional intelligence.

Project managers must deliver more value than the functional aspects of project management. As a program and project management consultant, I strive to build relationships and provide leadership. I want to go beyond scope, schedule and cost, and I expect the same out the project managers I work with.

If your business is in need of project managers who have the soft skills needed to respond to disruption, reach out to us at MacIsaac Consulting. We are here to be of service.

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.

 

Have People Had Enough Of Agile?

Agile Delivery

Photo Credit Shutterstock

If you work in a business that has anything to do with technology, you are familiar with Agile. You know the Agile I’m talking about. The kind where teams sit together and deliver software in increments. Seems everywhere you turn these days you hear about Agile. Along with Agile’s popularity has come a title wave of services. These services include coaching, training and certifications.

Consultancies have jumped on the Agile bandwagon big time. The other day I noticed a local consulting firm completely re-branded themselves. They are now the Agile experts. I was like wait, what? Like a year ago, they didn’t even provide IT consulting. Anyway, you get the point, Agile is the flavor of the moment and it’s everywhere.

Along with the over promotion and saturation of Agile, there has also been a mass influx of Agile gurus. These gurus scour the internet to prove their Agile knowledge is second to none. Agile to them has become a religion. They are quick to scold anyone blasphemous enough to challenge their Agile expertise. If you follow any Agile groups on LinkedIn, you’ve seen the ridiculous feuds. For sure the gurus will comment on this post to teach me the error of my ways.  Dealing with these gurus online is bad, but if you’ve had to work with them, it’s even worse.

So, between the obnoxious gurus and the commodification, I must ask, have people had enough of Agile? Is Agile software delivery like the glam hair metal of the 80s, and we’re at the point of Nirvana and grunge breaking onto the scene?  Keep in mind that as I ask this question, I’m a pro Agile guy. For many years, I studied and worked in both the Agile and traditional SDLC worlds, and today Agile is my preference. Although I’m a pro Agile, I’m concerned about what Agile has become.

To back up a bit, I started my career back in 2000 as a manual software tester, long before Agile exploded onto the scene. For years, I tested software for various organizations. Around 2008, I got introduced to Agile when I worked as a QA analyst on Scrum team. After time, I started working as an IT Project Manager and an Agile Scrum Master.

I studied everything I could on project management and on Agile delivery. I got my PMP and in business school I studied systems thinking and the theory of constraints. I attended Agile training, got a CSM (Certified Scrum Master) certification, and read every book I could on Agile.

Today, I still consult as an IT project/program manager or Agile Scrum Master. Although my preference is Agile, I’ll perform whatever the client role requires. Usually this means being a traditional project manager, an Agile Scrum Master, or a hybrid of both.

I have a real appreciation for Agile delivery. I found that the Scrum Master role coincides with two of my other passions, leadership and emotional intelligence. I love how Agile delivery is not only about writing code, but also about relationships and working together as a team.

As much as I’m a fan of Agile, I still think there is value in traditional project management. There are disciplines and processes that are tried and true in project management. We need to be careful not to write them off. Not all organizations are ready for Agile adoption, and that’s okay. I know that may sound odd coming from someone who is pro Agile, but if we are honest, Agile adoption is not easy. It isn’t as simple as attending a training. There are some great training services available, but often they have little effect.

All this leads me back to question, have people had enough of Agile? Am I, and pro Agile people like myself, part of the problem? Have we lost sight of the Agile Manifesto and become too dogmatic in our views, turning others off?

Soon Agile will morph into something else. New delivery frameworks will emerge, and so will new gurus. Whatever happens, it’s important we open ourselves up to not having all the answers, and we remain teachable. The main goal is that we continue to improve how we develop software and work together. To me, the Agile movement is a part of something bigger than certifications and gurus. It’s about working together to build quality products that provide value. What say you?

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.

Should a Scrum Master ever crack the whip?

Scrum Master

We know the Scrum Master role is different from a project manager. Scrum Masters are servant leaders, coaches and facilitators. Project managers are more aligned with command and control.

Does this mean that Scrum Masters should never crack the whip on the team?

Well, yes and no.

Just because Agile teams are self-organized, they sometimes still need to be pushed. Ideally the team will push themselves, but if that’s not happening then yes, the Scrum Master should put some pressure on the team. In Scrum, it’s usually the Product Owner who has some authority. Although the Scrum Master doesn’t have authority, they can vocalize the importance of getting work done (aka, crack the whip).

There are some misconceptions about Agile and Scrum when it comes to pressure. Some people think Scrum is a low pressure environment. Not true. In Scrum, they call iterations Sprints because teams are moving fast! There is pressure. There is also more visibility. Everyone can see what everyone else is working on in the Sprint. There is no hiding.

So, while cracking the whip usually aligns with project management, I do think it’s sometimes appropriate for Scrum Masters.

What are you thoughts?

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.

 

 

2 huge reasons your Agile team struggles to be Agile

agile teams

In my recent post, problems with Scaled Agile, I discussed SAFe and the Agile mindset.

Aside from debating the value in SAFe, the post created good dialogue about how to foster an Agile mindset within teams. That is, how to help teams become more collaborative, open and trusting.

In my experience, teams often struggle adopting an Agile mindset for two obvious, yet overlooked reasons.

Reason 1 – The team consists of people who don’t like Agile

Think this sounds silly? I can’t tell you how many “Agile” teams I have worked with that had team members who wanted nothing to do with Agile. Not only were they not drinking the Agile Kool-Aid, they were down right opposed to it.

Management makes a big mistake when the put people who aren’t on board with Agile on Agile teams. The thinking is that team members will come around and learn to embrace Agile values. Of course, this doesn’t happen.

John Kotter, Harvard leadership professor, gives great advice on dealing with change resistors. His message is to not try to include them in the change effort. This means, go around them or get rid of them. This may sound harsh, but trying to include anti Agile people in Agile teams causes too much damage.

Managers – When you are forming Agile teams, make sure you bring on people who want to be on an Agile team. The challenge though, is vetting out the Agile imposters.

Reason 2 – People assume roles that do not align with their personality.

The classic example of this is when a traditional project manager takes on the Scrum Master role. A big misconception is that the Scrum Master and Project Manager roles are interchangeable. The truth is the two roles are different. The Scrum master role is about servant leadership. This is different from project management which is more about command and control.

Want to know if a Scrum Master is behaving more like a Project Manager? Attend the team daily scrum and you will find out. If the Scrum Master controls the meeting, they are in project management mode. The daily Scrum is a team meeting, it is not meant for each team member to provide status to the Scrum Master.

Some people who are great Project Managers make lousy Scrum Masters, and vice versa. Make sure you put people into a role that best aligns with their personality and strengths. If you don’t, good luck trying to change someones personality to fit a role.

To recap, if you want an Agile team that embraces Agile values, start by getting the right people on the team. Do not form a team with people who oppose Agile. Next, put people in roles that fit their personality. Do not expect people to change their personality to fit a role.

Like Collins says, get the right people on the bus, and in the right seats!

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

Mike’s Twitter @MikeMacIsaac

To contact Mike, click here.

 

 

 

 

Why Cash is King

Cash Flow

If you work in technology like me, you may not think there’s a need to focus much on finance. It is important though to understand the numbers, especially in project management.  In my next several blog posts I’m going to focus on financial management. To begin, let’s start with the green hard stuff, cash.

When it comes to cash and business, there are three things to know. The first is that cash is not the same as profit. The second is that most companies fail due to a shortage of cash flow. The third is that the cash statement provides valuable insight into a company’s situation. That last point is particularly important if you are planning to buy stock in a company. Warren Buffet might be the world’s greatest investor because he understands cash.

Cash is not the same as profit

Profit is the amount of revenue generated minus all expenses, what you have left is profit. So what is the difference between cash and profit? First cash doesn’t reflect money coming in through earned operating income. The cash may be coming in through loans or investors and that money doesn’t show up on an income statement.

Money from recorded profits isn’t received until some time after the transaction takes place. In an all cash transactions the funds will placed directly into the sellers account.  Small companies that are growing and creating profit, but not receiving the cash needed to keep up with expenses, run into trouble. This leads to the next topic which is that most companies fail due to a shortage of cash flow.

Most companies fail due to a shortage of cash flow

Profitable companies can go out of business if they don’t have enough cash. What happens is that they are continually waiting to receive cash to keep up with their expenses. An example would be as follows: Company A is a startup which over its first several months of business has recorded good revenue gains and large profits. The transactions for the products the company sells take 4-6 weeks for the funds to arrive. Due to the delay in receiving payments, the company does not have enough cash in the bank to cover the costs of operating expenses and growth. This ends up being a continual game of catch up with the actual cash behind the recorded profit. For most companies and startups it won’t be sustainable.

By reviewing a cash statement you can gain valuable insight into a company’s situation and where it might be headed

Income statements are complex and can be deceptive. The numbers can be manipulated by accountants to appear as though company is in better shape than it actually is. Most of the expenses on the statement haven’t been paid during the time of the statement.

Cash statements give an accurate view of how much cash was received and paid within a certain period. The cash flow statement can not be altered by the accountants like the income statement can be. Due to this, the cash statement gives great insights to investors because it paints a clear picture of how the company is doing.

In a sense the cash flow statement is a way of looking into a company’s bank account. The cash flow statement can provide valuable insight into a company’s future. If investment money is coming in, that may be an optimistic sign for the future. It could also mean that the company is selling stock to stay afloat. Looking at the cash flow statement may generate questions, but they are the right ones to be asking.

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

Follow Mike on Twitter @MikeMacIsaac

To contact us about our services, click here.

Why robots won’t provide as much value as people in the future

As we go about our daily busy lives, it’s easy to lose sight that we are in midst of a digital revolution. We take for granted what we are now doing through technology.  Using smart phones for Uber, tracking our daily activity through wearable devices, or speaking to an Amazon Echo are examples. It is incredible how fast technology has evolved. Yet, we are only in the infant stages of the digital revolution.

digital revolution

The digital revolution brings about great opportunities for business. This is particularly true for services using IoT (internet of things), Big Data, and Cloud based technologies. Expect that you will see an increase in AI (article intelligence), automation, and robots. Self driving cars, unmanned aircrafts, and smart devices have become a reality.

This advance in digital technology has left many in fear of losing jobs to robots, and for good reason. In a recent study done by the Korn Ferry Institute, 67 percent of executives said they would value technology more than people when looking at the next five years. The idea is that workers will be unnecessary due to robotics, automation and AI.

While there is no doubt that technology will replace many manual jobs, here’s the good news. Human capital will still hold the greatest value. Why? The main reason is that humans continue to gain knowledge and experience over time. In a sense, they appreciate in ways that machines cannot.

It is my position that as the world becomes more digital, we will see a greater demand for human capital.  It’s ironic but the advance in technology will provide a need for human connections. This means people will need skills based on strong emotional and social intelligence. This also holds true for technical leadership and project management positions.

Executives then need to value both human capital and technology. They need to find the right balance between the two. It would be a mistake to go all in on technology and lose sight of human capital importance. It seems most CEOs currently don’t grasp this. As CEOs face intense pressure to increase organizational performance, they focus on what they can measure. Robotics and automation give CEOs the comfort of figures and metrics that help them make projections about the future.

These metrics and data driven forecasts leave CEOs with a blind spot. What they don’t see, or can’t measure, are the human factors effect on performance. “Actually, the most important figures that one needs for management are unknown or unknowable, but successful management must nevertheless take account of them.” (Lloyd S. Nelson)

You can’t measure the positive effect of a warm and empathic interaction between a customer and an employee. The convenience and performance of machines could never replace our core need for social interaction.

So as you plan your strategy during this time of digital revolution, tap into what you already understand. People are the most valuable assets within an organization.

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

To contact us about our services, click here.

References

http://static.kornferry.com/media/sidebar_downloads/KF1046_FOW_WP_AW_171116-4.pdf

http://www.bizjournals.com/twincities/news/news-wire/2016/11/18/a-robot-could-take-your-job-and-your-manager-might.html

 

Page 2 of 5

Powered by WordPress & Theme by Anders Norén