Category: Project Management (Page 1 of 3)

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.

A Realistic Look at the Agile Manager

Agile Manager

Often you will hear that the biggest challenge to Agile adoption is management. There is little doubt about this. Adjusting to an Agile mindset for many managers is difficult. This is especially true for managers who only know a command and control environment. It also doesn’t help that most business schools teach outdated management theories. Agile requires a new way of managing based on coaching and empowering others.

It is important though to realize that manager’s still play a key role in Agile. Just because the Scrum Guide and Agile Manifesto pay no mention to managers, it doesn’t mean they aren’t needed. To the contrary, in my experience good managers are crucial to the success of Agile delivery. Management shouldn’t be a bad word!

Let me provide a scenario. An Agile team was on track to a deliver a product to a very important customer. The team misses their promised delivery date and the customer is irate. In a situation like this, should executives look to the entire Agile team to understand why the delivery date was missed? No, they shouldn’t. In this situation, a manager should be the one to explain to the executives what happened, and take the heat. The manager would also provide direction to go forward. It’s the manager’s responsibility to communicate with leadership and, well, to manage.

Agile is about empowerment and trust, but this doesn’t mean we abandon management. If we did, it would be chaos. The notion that managers relinquish all control to delivery teams is naive. It’s also irresponsible. Agile purists envision a Utopian world of people working together in harmony. They long for a workplace where people are never told what to do. The reverse is the old school manager, who wants to make all the decisions. Neither one of these approaches are adequate. The key to management is balance. This brings me to the Agile manager.

The Agile manager empowers teams, but also knows when to step in. They are servant leaders first, but they know when to manage. The idea that managers should never put pressure on teams, or tell anyone what to do, is a fantasy. As Agile continues to evolve, we can’t see management approaches as black or white. Agile managers must be flexible. The best teams evolve from a diverse management approach.

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.

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.

 

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

 

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.

 

5 reasons project managers make lousy scrum masters

Lousy Scrum Masters

As the Agile movement continues to grow, the demand for scrum masters has increased. Traditional project managers have caught on and they’re disguising themselves as scrum masters. With a small fudge of the resume, they’re hired as scrum masters. What’s the problem? Project managers make lousy scrum masters.

Now, don’t freak out and get offended. When I first began working as a srum master, coming from an IT project management and QA background, I was lousy. I had a steep learning curve. It’s only after time and working with good Agile coaches that I’ve been able to improve as a scrum master.

The reason we project managers make lousy scrum masters is simple. The two roles are completely different. The original founders of scrum have made it clear that a scrum master is not a project manager. For a description of the scrum master role, check out the Scrum Guide from Scrum Alliance.

Yet, companies continue to hire project managers as scrum masters. Part of the problem is that most business executives don’t understand Agile. I still hear the question from management, “hey can you do that project using Agile”? As if Agile is something you can decide to use like choosing which fuel to pick at the gas station. Agile is a different way of working and thinking. Agile adoption requires commitment and understanding from teams and leadership.

Okay, I’ll get off my soap box. Without further ado, here’s my list of 5 reasons why project managers make lousy scrum masters:

  1. The concept of self-organizing teams doesn’t register with project managers. This may be the most challenging aspect in Scrum for project managers. Project managers are hardwired to tell teams what to do and when to do it. They then expect a full status back in return. In Scrum, the team decides what to work on with guidance from the product owner. The team is then accountable to each other, not to the scrum master. During the daily Scrum, team members should be giving their updates to the team, not to the scrum master. Keeping quiet and letting the team be accountable makes project managers feel like fish out of water.
  1. Project Managers aren’t used to coaching. On traditional projects the project manager is a leader and decision maker. In Scrum, one of the primary roles of the scrum master is to coach the team. They coach in self-organization and cross-functionality. To be able to coach though, one first needs to learn. If the project manager hasn’t learned Scrum, how could they coach the team?
  1. Project Managers struggle to give up being the top dog. On traditional projects, the project manager is the top dog. The buck stops with them. As a project manager, it feels good to have authority and control. In Scrum, you have to let that go. The scrum master does not have authority. The team does not report to the scrum master. The one who has authority on the Scrum team is the product owner. This fact requires project manager to have humility when transitioning to Scrum.
  1. Project managers freak out without a plan. The Project Management Institute teaches project managers to create plans, for everything. If you have your PMP, you know that they expect you to create a giant plan (document) consisting of like 10 sub plans. This plan, the size of the PMBOK, does not change unless there’s some official change request. While Agile still involves planning, this is completely different from Scrum.
  1. Most project managers don’t understand servant leadership. Scrum masters are servant leaders. This means they’re willing to jump in and do whatever it takes to remove impediments and help the team. That might mean helping to dive in and handle low level administrative work. Scrum masters put their ego aside and serve the team. Instead of puffing out their chest and telling everyone what to do, the Scrum Master asks how they can be of service. Most project managers are not used to this style of leadership when they begin in Scrum.

Here’s the good news, it is possible for project managers to become good scrum masters. It takes time and training. It’s like learning to play both guitar and drums well. Yes both instruments create music, but they need different training and skill sets.

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.

 

 

 

 

 

Every IT project is a unique composition

IT Project

A musical composition tells a story. Take for example, Mozart’s Requiem: Lacrimosa. As the music begins, the sounds of the soft strings and chorus provide a sense of mystery. The sounds fill you with wonder as you chart off into the unknown. The story has begun.

As the sounds and tempo begin to intensify, you go on an emotional ride consisting of high peaks and low valleys. The music eventually softens and the piece concludes. The story comes to an end.

In the same way, each IT project delivered is a unique composition that tells a story. Like Mozart’s Requiem: Lacrimosa, projects often begin with a sense of wonder. As you discover the project scope, it’s like the beginning of roller coaster ride. You slowly climb high into the sky. Filled with excitement and nervousness, you look around and realize you are in for a wild ride.

Suddenly, whoosh! You hit max speed into your first steep drop. The orchestra is playing at a pulsating high volume. The story has changed. No longer are you in the beginning of a discovery phase accompanied by soft strings and chorus, you are now surrounded by danger and chaos. Hold on because it’s going to be a wild ride.

Delivering the scope of your IT project will be as intense as Beethoven’s 5th symphony. Up until this point you only had a plan, but now you are in execution, where things get real.

Coming at you all at once are change requests, deadlines, defects and personality conflicts. These are just a few of the components that make up the challenges of the project story. On the flip side, team work, achievements, and feelings of accomplishment provide the high points.

The cast of the story usually includes a range of characters. Business executives, managers, team members and stakeholders all have a role to play. The main protagonists of the story are the project team members. For the story to come together like a great musical composition, everyone on the team needs to be in sync.

The leader of the team needs to be passionate, like an orchestra conductor. An orchestra conductor can hear the music so clearly that he or she can direct changes simply by waving their baton.

The project leader must do the same to keep the team on track. They need to direct the story and guide it to completion. If anyone is out of tune or out of sync, the project lead must correct it immediately.

In the end, all IT projects will complete. Whether they are successful or not, the music will fade away and the project team will move on. The story will come to an end.

The team then moves onto another project, where a new story will begin.

 

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

Mike’s Twitter @MikeMacIsaac

To contact Mike, click here.

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.

Page 1 of 3

Powered by WordPress & Theme by Anders Norén