Want to Boost Your Scrum Projects’ Success Rate by 50%? Run Them Through a PMO
By J. LeRoy Ward, PMP, PgMP, PfMP, CSM, GWCPM, SCPM | Executive Vice President – Enterprise Solutions, IIL
Catch LeRoy’s presentation, “Agile: The One Bandwagon You May Want to Jump On!,” at the virtual Agile and Scrum conference on May 4th.
The 2015 State of Scrum Report (the most recent) released by the Scrum Alliance has several interesting, if not head-scratching, findings. Here are two that really stopped me dead in my tracks.
First, the report stated that “the overall success rate of projects delivered using Scrum is 62%.”
This floored me. Why? Given all the hype and hoopla about Scrum and all of its intended benefits, I would have assumed that this number would be quite a bit higher. Heck, 62% isn’t much better, if it’s better at all, than projects completed with more traditional methods. Why go through some wrenching organizational change, the change that Scrum often means for large traditional IT shops, when, in the end, the result is the same?
But it was the second finding that got my attention, and fast.
The report also disclosed, based on the respondents answers, that “Scrum projects run through a project management office (PMO) have a 93% success rate.”
That’s a 50% improvement over Scrum projects not run through a PMO. A 50% improvement in almost any measure is simply astounding. Hey, look at it this way, if your boss called you into his office and gave you a 50% raise that would get your attention wouldn’t it? You bet.
Unfortunately, the survey offers little if any insight as to why running Scrum projects through a PMO results in such a performance boost. Apparently, they didn’t have any follow-up questions such as “Why does the PMO matter so much?” Or, what’s the ONE THING a PMO does that really makes a difference when implementing Agile?” Too bad. That’s a lost opportunity to help organizations understand what services a PMO provides that can lead to such gains. Maybe the Scrum Alliance will add those additional, clarifying questions, in their next survey. I hope so.
Let me offer a few plausible reasons why a PMO can help improve Scrum project success.
To do so, I reviewed the results of a number of “State of PMO” and “State of Agile” reports for some answers. In one report, when respondents were asked “Why is Agile difficult to implement?” the answers included:
- Changing the culture
- Changing from traditional methods
- Right leadership to drive change
- Upskilling teams
- Understanding Agile’s value
- Motivating teams to use Agile
Perhaps running Scrum projects through PMOs who were catalysts in changing the culture, who helped folks change from traditional waterfall to Scrum with concrete suggestions, who had the type of bold leadership required, and who made sure all the folks involved in Scrum projects were trained, and not just the Scrum masters, were reasons for greater success.
Other findings in these various surveys reveal that not many PMOs are taking the “bull by horns,” or any other sensitive place (like the tail!), to help with a transition to Agile methods. For example, when asked “How are PMOs supporting Agile?” only 4 in 10 said they were providing Agile training, and only a third claimed they were helping with a new methodology, approach or new reporting processes. Twelve percent didn’t even know how the PMO was helping. That’s not a significant level of engagement.
Hundreds, if not thousands, of organizations have bought into the promise of Agile, yet by all accounts an overwhelming majority are struggling to implement it.
The PMO has a huge role to play, and when done well, working in conjunction with a committed Senior Management team who invests in Agile training and change management practices, the results can be astounding.
A 50% improvement in project success should have every Senior Executive working with his or her PMO manager to see if they can realize those types of gains. Sitting around bellyaching about poor project performance when opportunities to improve are staring us all in the face should prompt action, and FAST.
More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.
Ready to improve your project success rates? IIL can help. Request a free consultation today.
[trx_infobox style=”regular” closeable=”no” icon=”inherit”]
About the Author
J. LeRoy Ward is a highly respected consultant and adviser to Global Fortune 500 Corporations and government agencies in the areas of project, program and portfolio management. With more than 38 years of government and private sector experience, LeRoy specializes in working with senior executives to understand their role in project and program sponsorship, governance, portfolio management and the strategic execution of projects and programs. [/trx_infobox]
Do Too Many Cooks Spoil the Broth? In Scrum They Do!
By J. LeRoy Ward, PMP, PgMP, PfMP, CSM, GWCPM, SCPM | Executive Vice President – Enterprise Solutions, IIL
Catch LeRoy’s presentation, “Agile: The One Bandwagon You May Want to Jump On!,” at the virtual Agile and Scrum conference on May 4th.
How many cooks do you need in a kitchen? The answer is you can have as many as you like as long as one is the boss. If you don’t have a boss, there’s chaos.
In a kitchen, there is one that is the boss, the Executive Chef (often called “Chef”), and he or she calls the shots. Everyone else (such as the Sous Chefs, Pastry Chef, Line Cooks and all the other kitchen staff) knows exactly how the system works and who’s in charge. In fact, this hierarchy works very well. Just look at any major restaurant or hotel kitchen and you’ll see exactly what I mean. (I’ve worked in restaurants large and small, independent, and as part of a large resort hotel, and I can tell you the Chef is indeed the boss!) Do you think for a second that Gordon Ramsay, Bobby Flay or Mario Batali is not the boss in their kitchens? Think again.
But in Scrum, too many “cooks,” or Scrum team members, really do spoil the “broth” (read: project). Why? Because in Scrum there is no “boss.”
The Scrum team is supposed to be a self-organizing body who figures things out on their own. There’s no Project Manager barking out orders, and the Scrum Master’s role is limited to ensuring the Scrum process is being followed and no one bothers the team.
According to The 2015 State of Scrum Report published by the Scrum Alliance, Scrum teams averaged seven members. The recommended size range is seven, plus or minus 2. Respondents in IT/software development reported an average team size of 6.6 members.
Team size evidently does have an impact of Scrum success. For example:
When there are 4-9 members on a team, Scrum is successful 77% of the time.
When there are 10 or more, Scrum success drops to 65%.
When there are 3 or fewer on a Scrum team, the success rate is only 50%.
So, not only does having more than the recommended number of members negatively impact success, so does having fewer than what’s recommended.
To be sure it’s difficult to self-organize when there are more than 10 team members. First, if everyone is ostensibly equal on a self-organizing team then everyone will have their say, resulting in a large number of opinions that have to be discussed and debated (sometimes endlessly). While the ultimate decision may be sound, oftentimes these kinds of discussions end in compromises. And while a compromise decision may soothe the egos of those involved, it may not be the best one for the project.
I also think that too many team members invoke an Animal Farm mentality, which you will recall if you read Orwell’s classic, can best be expressed and rephrased as:
“All Scrum team members are equal, but some are more equal than others.”
When the “more equal” members assert their influence, the others either fall in line, rebel, or become alienated. Hardly the end result anyone wants from a self-organizing team.
With three or fewer team members, I just don’t think there’s enough diversity of experience and ideas to reach the best decision. Three’s a crowd, as the old saying goes, and perhaps some issues arise when two members feel strongly about one course of action, and the holdout has to simply agree. If that happens enough, the third wheel, as it were, stops rendering his or her opinion.
So, we’re left with seven (plus or minus two) as the optimum team size in Scrum. But wait a minute, seven has always been touted as the optimum number of team members in project management, at least for the core team. So, what’s the big deal about Scrum and the number seven? Not much really, and that’s the point.
We can apply many of the best practices we’ve used all these years on traditional projects on our Scrum projects and, in fact, we should. After all, our only goal is to get the project done successfully. However way gets us there is the route we should take.
More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.
Ready to improve your project success rates? IIL can help. Request a free consultation today.
[trx_infobox style=”regular” closeable=”no” icon=”inherit”]
About the Author
J. LeRoy Ward is a highly respected consultant and adviser to Global Fortune 500 Corporations and government agencies in the areas of project, program and portfolio management. With more than 38 years of government and private sector experience, LeRoy specializes in working with senior executives to understand their role in project and program sponsorship, governance, portfolio management and the strategic execution of projects and programs. [/trx_infobox]
The Secret to Being a Great ScrumMaster or Agile Coach: The People Chip
By Angela Johnson | Certified Scrum Trainer & Agile Transformation Coach
Catch Angela’s presentations “Are you a Credible Agile Leader?” and “Is your Daily Scrum Dysfunctional?” at the virtual Agile and Scrum conference on May 4th.
Why do Agile or Scrum trainers seem to walk in “off the street” and immediately pinpoint the people problems?
Clients and students repeatedly ask, “How do you know that?” “Who is giving you this information?” They are dumbfounded when the response is, “Nobody gave me this information. I picked up on the issues right away.”
How have I cultivated this “people chip?” Is it because of Certification as a Scrum Professional or Trainer? Am I psychic? Hardly!
I simply pay attention. I am not “tuned out” looking at a device or taking notes. I am actively employing the Scrum values of Focus and Respect – giving full attention to the conversation and interactions at hand in coaching or training sessions.
This means being present in the moment. The people chip becomes calibrated because Scrum is the way to do the work – not something viewed separately from the way the work has traditionally been done.
Looking directly at people in coaching conversations reveals far more from their facial expression, their body language, etc. in addition to the words that they use. Actively listening means not talking or waiting to talk – but hearing what the person is saying. Sometimes that involves what they are not saying verbally.
Coaching may result in paraphrasing what was said to ensure that I am understanding the true nature of the problem trying to be solved and not making incorrect assumptions. Asking a number of questions can also help get the person “diagnosing” their own issue and help them brainstorm a list of possible next steps to take or next conversations to have in their team or organization.
Want to begin calibrating your People Chip? Try these two tips:
-
Stop being the Product Owner or Team’s Secretary
Do you feel like you have to be writing or typing in order to add value? Are you updating charts, tasks, typing into some sort of tool? What are you missing because your Focus is elsewhere? You could have been asking a question to get things moving in the right direction, observed body language that let you know everyone was not in agreement on what Done looks like, or picking up on any number of things.
-
Stop being the Authority on the Product or Technology
As the ScrumMaster, or certainly as a Coach, you are neutral. This means that you do not assert an opinion on the Product or the Technology. If you do that you are enabling the wrong behavior. Hand someone a fish and they have food for today. Teach them to fish and they have food for a lifetime. Your job as the ScrumMaster is to cultivate and enable cooperation, collaboration, and teamwork to lead the Product Owner and Team to consensus. You do this through planting seeds, asking questions, and getting the right people together to work on the problem at hand – not by being the authority on any technology or product attribute.
More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.
[trx_infobox style=”regular” closeable=”no” icon=”inherit”]
About the Author
Angela Johnson, PMP, PMI-ACP, CST is passionate about changing the world of work. She seeks to help people and organizations to break down their barriers and work together in a collaborative way. Angela facilitates the PMI Minnesota Agile Practitioner Community and serves on the Scrum Alliance Trainer Approval Committee. [/trx_infobox]
Scrum for Hardware
By Hubert Smits | Management Consultant, SmitsMC LLC
“The rules of the game in new product development are changing. Many companies have discovered that it takes more than the accepted basics of high quality, low cost, and differentiation to excel in today’s competitive market. It also takes speed and flexibility.”
Takeuchi and Nonaka wrote this paragraph back in 1986, and it inspired people to develop Scrum as a way to develop software faster, better and cheaper. Over the last 15 years the Scrum approach has proven to work in many different projects and it has also proven that Scrum is “simple, not easy”.
The general opinion is Hardware (i.e. cars, photo copiers, combine harvesters) cannot be developed with Scrum. The plan-do-inspect cycle of just 2 weeks is considered too short, teams cannot deliver a satisfactory next version of a product under development that quickly. However, I’m here to tell you that experience proves this assumption wrong.
Fifteen years ago I had discussions with many people who were convinced that big software projects, high risk software projects, or software package implementations wouldn’t fit in a Scrum framework. Nowadays projects with 1,500 participants have shown to be successful. Government agencies are firm believers in Scrum. Just like critics in software were proven wrong, so will critics of ‘Scrum for Hardware’!
More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.
[trx_infobox style=”regular” closeable=”no” icon=”inherit”]
About the Author
Hubert Smits has been working with Scrum for over 15 years, and as a Scrum trainer for over 10 years. While training all around the world he built a broad and deep experience with Scrum in many domains. Recently he is applying it to develop hardware, like the Wikispeed car.[/trx_infobox]
Agile, Scrum, and Kanban: What the Heck Do These Words Really Mean?
Join IIL’s virtual conference on Thursday, May 4th for more insights on Agile, Scrum, and Kanban.
BY GORAN PRIJIC – FREELANCE SOFTWARE ENGINEER @ TOPTAL
Agile
If you want to be the smartass of the crowd, you should use the word “agile” in every other sentence when you are talking about the work process. It has a pretty wide range, does not obligate you to know much about the subject you are talking about, and it is a really nice adjective or adverb: “thinking agile,” “agile approach,” “according to agile principles.” But what does “agile” really mean?
“Agile” refers to “agile software development,” the approach to development that follows agile principles. But what the heck are “agile principles?” Take a look at the Agile Manifesto and at the 12 principles of agile, which lay the foundations of agile development. From the 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
Agile is a framework for thinking and making decisions.
The Manifesto and principles are the result of searching for the best solutions that have evolved over the decades in response to the challenges of software development. Throughout the 70s, 80s, and 90s, different developers and teams all over the world had been experimenting with methods of working and approaches to problem solving, inventing different frameworks and techniques (such as scrum and Extreme Programming), and even coming to the same ideas in parallel. Finally, in February 2001, seventeen developers got together and found the common denominators for all these diverse ideas and experiences. That is how the manifesto was created.
The Agile Manifesto is the result of different experiences and practical solutions that emerged over the decades.
Scrum
If you talk about “agile” methods without knowing what they mean, you may slip up and say things that will uncover you in front of the interlocutor who knows the subject: “Scrum and other agile methodologies.”
Scrum is not a methodology, though we’ve all heard it called such more often than the number of killings inGame of Thrones. Scrum won’t give an answer to every question, and it won’t provide you with the precise procedure for responding to every situation you face. And probably as a result of this incorrect interpretation, most scrum implementations are also wrong: Teams don’t get value. This results in probably the most foolish statement about scrum: “Scrum doesn’t work.”
What is scrum? The Scrum Guide defines scrum as:
“A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.”
Scrum consists of three roles: Product Owner, Scrum Master, and Development Team; four ceremonies:Planning Meeting, Daily Scrum, Sprint Review, and Sprint Retrospective; and three artifacts: Product Backlog, Sprint Backlog, and Product Increment. It is organized into regular time frames, which we callsprints. Sprints should last between one and four weeks.
The Product Owner, or PO, is responsible for guiding the project’s direction. As new tasks and features are determined, the PO adds them to the Product Backlog. A sprint starts with a Planning Meeting where theDevelopment Team selects the tasks from the Product Backlog to work on and plans how they will be implemented. That is followed by development, during which the Dev Team uses the Sprint Backlog to track progress and meets for the Daily Scrum in order to synchronize activities and adjust the plan, if needed. The result of development should be a Product Increment, something that can be applied to the product and released immediately. At the end of the sprint, the Product Increment is presented to the Product Owner at the Sprint Review, where the product backlog is augmented if further changes are needed. Afterwards, the whole team attends the Sprint Retrospective (also known as the Pub Meeting) where they talk about the work process and how it can be improved.
That’s it in a few sentences, but if you need a detailed explanation of how scrum works, check out this article written by yours truly.
It is easy to learn and understand scrum, but it’s hard to adopt. There are many reasons this framework may or may not be a good fit for a project. It often requires a lot of changes, not only in everyday development, but also culturally. Scrum fits best with development of complex products, ones that last a long time and that include different kinds of specialists.
Why is scrum so popular, and why does it have an advantage over the traditional waterfall model? Simply put, because it delivers more value to a product and customers. With “heavyweight” methods such as waterfall, horror stories abound in which nobody sees anything of the project for months. With scrum, that is not possible.
Scrum is all about the value that is delivered to end users. If you really utilize scrum, you need to deliver something of value every sprint. The value can be measured, and the team is also forced to inspect impediments and adapt, with the goal of delivering more value in the next iteration.
In most software development we are not building a skyscraper; we don’t need to have the whole plan ready before we start, and stick to that plan until the end. We are developing software, and we have the ability to adapt to different situations and to change the product requirements during development. For a long time, many developers saw this as the eighth deadly sin, but from the product perspective it is a huge benefit for optimizing predictability and controlling risk. Scrum is developed around this ability, and its implementation gives a reliable and efficient way of dealing with necessary changes.
Many techniques are used in conjunction with scrum: planning poker, pair programming, test-driven development (TDD), behavior-driven development (BDD), and others. They are not really a part of scrum, but rather compatible techniques. One method often mentioned at the same time as scrum is kanban, and there is a lot of confusion about what these two things mean in relationship to each other.
Kanban
When you talk about scrum and kanban, one frequently asked question from the crowd will be, “Which is better, scrum or kanban?” And you won’t know what to answer because it’s like comparing apples and oranges, or asking, “Which is better, pancakes or beer?” Both are better.
Kanban is a simple method that aims for just-in-time delivery while not overloading the team members. It is similar to scrum in that the goal is to deliver maximum value at the end, but it is much more flexible than scrum.
Kanban was not invented by the software development community. In fact, it has its origins in manufacturing processes at Toyota, and it has wide usage in other spheres. There are no strict procedures that you should follow, and no strict way you should implement and use kanban; it is, rather, a set of principles and practices, and you can choose from these practices to suit your needs. But there is one most-often used implementation of kanban in software development that includes the usage of a kanban board, consisting of columns representing stages of work, and tasks.
Columns represent the state of a task in the development process. The simplest example consists of three columns: “To Do,” “In Progress,” and “Done.” So, tasks are added to “To Do,” moved to “In Progress” when development starts, and considered “Done” when moved to the last column. But of course, it could be more complex:
“Backlog” → “Defining Specification” → “Ready for Development” → “Development” → “Code Review” → “Testing” → “Deployed” (→ “No one really uses it” → “Completely Removed”).
Every column can have subcolumns; for example, “Development” can be divided into “Planning” and “Coding”; “Testing” can be divided into “Unit Testing” and “Integration Testing,” and so on. Columns might be dedicated to specialists, if appropriate. The team defines the columns and stages according to its needs. Per the “pull” philosophy, tasks should only enter the workflow when the demand for them is immediate.
The purpose of this board is to visualize the workflow, which is the first key practice in kanban. In fact, kanban can be done without a board at all! It could be a simple list of tasks in a Google sheet with different background colors indicating the state of the task, or it can be Gantt charts, diagrams, tables… It could even be a set of buckets in your office, where each one represents the state of the task, and where balls are used as tasks. Just visualise the workflow and provide transparency to the whole process.
Another important principle is to reduce the batch size of your efforts. Simplified, this means avoid multitasking. That can mean reducing the volume of tasks you work on at the same time. If you have three designers in a team, the team might set the maximum number of tasks in the “Designing” column to three.
Like scrum, kanban also sees the team as the most important figure in the process. But it doesn’t suggest roles as scrum does, and you may keep the existing roles to avoid making changes to your existing process. The same stands for continuous improvement: Kanban generally encourages you to learn and improve continuously, but does not prescribe a specific event just for that process, as does scrum’s Sprint Retrospective.
Which Should I Use?
Scrum and kanban are not mutually exclusive and not really comparable. In scrum, there are defined roles, while kanban says, “What the hell, keep your current roles and responsibilities.” Scrum will force you to change your way of working; kanban lets you start with your existing process. In scrum, a clear schedule for events is prescribed by the framework; in kanban you don’t have events. Yet, they have a lot of similarities: Both are value-centric, team members are respected as “bosses” of the system, and essentially, they have the same mission: To continuously eliminate waste and remove obstacles.
But the question, “What should I use in my particular project and with my particular team?” makes much more sense. Kanban doesn’t require so much of the process and cultural changes, and, in most cases, it will be easier to adopt than scrum. Scrum, on the other hand, offers significantly more structure to guide the process, which can eliminate a great deal of overhead as long as everyone is on the same page.
But the beauty of both is that neither is a strict set of rules. There is nothing stopping you from picking and choosing the best scrum elements for you, such as a daily meeting or review. And there is no reason you cannot incorporate a kanban board into scrum.
Scrum has proven to be a highly effective framework when the whole team understands it well. However, in my experience, I find it hard to work in scrum with some clients. The process and cultural changes required for proper scrum implementation can be too much (especially when dealing with someone who believes that he is making a new Google!). On the other hand, kanban is more flexible and doesn’t force people to change. Some authors also say that kanban is a good path to agility, and offers easier implementation of scrum. Others say that using scrum should lead to kanban at the end.
The truth is that every project is different, and there is no one-size-fits-all solution. As a project manager, it is up to you to determine what works best for your team.
More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.
In Scrum, Everything is 100% Complete. Really? Not So Fast!
By J. LeRoy Ward, PMP, PgMP, PfMP, CSM, GWCPM, SCPM | Executive Vice President – Enterprise Solutions, IIL
Catch LeRoy’s presentation, “Agile: The One Bandwagon You May Want to Jump On!,” at the virtual Agile and Scrum conference on May 4th.
Years ago I worked with a guy whose last name was Dunn. My boss used to call him “not Dunn” because he never seemed to be able to complete anything. That always made me laugh, but in the end, it’s not really that funny because if people can’t finish anything then chances are they get a pretty bad reputation in a company.
I thought of him while reading The Scrum Guide™, authored by Jeff Sutherland and Ken Schwaber. One of the three tenets of Scrum Theory is Transparency which the authors describe using two examples. One of them is as follows:
Those performing the work and those accepting the work product must share a common definition of ‘Done.’
The concept of percent complete has always been subject to a wide range of varying definitions and interpretations. What is 50% complete to one person, or group, may not be to another.
For example, the project manager may report that the project is 50% complete because half the resources and costs have been incurred and the deliverables are well on their way to being completed (even though nothing has been delivered yet).
The client, on the other hand, who may also be obligated to making progress payments based on percent complete, may think it’s a lesser percent because they haven’t received half the benefits or inspected or reviewed “half” of the deliverables. Without an adequate inspection system, or prior agreement as to what 50% complete means, it’s one person’s word against the other’s.
Let me present an interesting example.
I took this picture of the front window of the Metropolitan Transit Authority’s (MTA) Project Office on 2nd Avenue in Manhattan. The sign informs the neighborhood the progress made on this megaproject. As you can see, MTA reports the project is 82.3% complete.
What does that really mean? Does the .3% make you feel that they really know what they’re talking about because it conveys a sense of accuracy? Your guess is as good as mine.
As a consequence, it’s always been sort of a game, and a guessing game at that, to determine percent complete. It’s a lot more art than science. And, when you add the obligation of progress payments based on percent complete, disagreements are more the norm than the exception.
I don’t see this issue magically disappearing because of the concept of Done in Scrum. As far as I can tell, what is Done is the deliverable to be produced at the end of the Sprint. But what percent complete is the entire project based on one deliverable generated by one Sprint? It’s a rhetorical question, so if you have a rhetorical answer please speak up!
I have no issue with Done; in fact, I think it’s a great idea to have all parties agree as to what that means. But to avoid potential disagreements I think the lessons of the past can apply to Scrum projects as well.
For example, in the earned value method (EVM) a task was recorded 50% complete the day it started, and 100% complete the day the requirements were met. This took all the guesswork and differing interpretations out of the equation so that the project manager and client could at least agree, at a high level, just how far along the project was and how much the buyer had to pay the seller. Might this work for Scrum? Maybe, maybe not.
As for this post, I think I’m Done!
More insights await at the virtual Agile and Scrum conference, going live on May 4th. 5 keynotes and 20 sessions to choose from, plus networking and PDUs/SEU®s.
[trx_infobox style=”regular” closeable=”no” icon=”inherit”]
About the Author
J. LeRoy Ward is a highly respected consultant and adviser to Global Fortune 500 Corporations and government agencies in the areas of project, program and portfolio management. With more than 38 years of government and private sector experience, LeRoy specializes in working with senior executives to understand their role in project and program sponsorship, governance, portfolio management and the strategic execution of projects and programs. [/trx_infobox]
The 10 Best IT Jobs in America Require Serious Project Management Skills
By J. LeRoy Ward, PMP, PgMP, PfMP, CSM, GWCPM, SCPM
Executive Vice President – Enterprise Solutions, IIL
CIO Senior Writer Sharon Florentine has developed a slideshow entitled “10 best IT jobs in America” using information from Glassdoor’s annual “Best Jobs in America” list for 2016. It’s quick and easy to read, and anyone in IT, or anyone looking to get into the IT field, will find her article interesting for many reasons (not the least of which is the salary range for each position!).
But what I found most interesting is that every single one of these IT jobs requires some level of project management experience, business analysis competence, and leadership and team-building skills. For a lifetime student of project management like me, you could see why this is so fascinating. In many of these jobs, the more experience in project management and these other critical skills, the better.
So, what are the 10 best IT jobs in America today?
Here’s the list (you can read a brief description of each role in the slideshow):
- Data Scientist
- Solutions Architect
- Mobile Developer
- Product Manager
- Software Engineer
- Analytics Manager
- Software Development Manager
- QA Manager
- UX Designer
- Software Architect
Why do I contend that the folks doing these jobs need serious project management and other “non-technical” skills?
Here are a few reasons why. See if you agree.
-
All of these jobs require the individual to work on cross-functional teams, and each team member brings different skills, personalities, and level of experience to the effort.
IT folks can’t be “lone wolves” locked up in solitary confinement, throwing solutions over the wall to users and clients. Companies have tried that for years with little to show for it. IT professionals must work shoulder-to-shoulder with users and clients to understand their needs through iterative processes so that they can produce the desired solution or product. Let’s face it—working with clients and users can be a messy business for a variety of reasons, so having refined interpersonal skills (which isn’t something many IT folks are known to have) will go a long way toward providing a harmonious working environment. This usually results in better products getting to market quicker. And, what company doesn’t want that today? No company I know.
-
These IT positions require that the individual have a strong background in various software development approaches: The Scrum approach in particular, waterfall, and more increasingly, Agile.
That’s a whole different ball game than a traditional approach to software development. Scrum, in addition to other significant differences from the waterfall method, requires the team to effectively manage itself, relying only on the Scrum Master to ensure that Scrum practices are followed. The Scrum Master is not there to “call the shots” as generally practiced in traditional command and control project management (an approach which is increasingly becoming discredited as a way to manage). In a word, each job requires a very high level of discipline on the part of the IT professional to work well with the team and participate in the necessary collective decision making to get the project done.
-
Many of these jobs demand that the IT professional have a deep understanding of what I call the “business of the business.”
In other words, the more the IT pro knows about how the business operates, how it makes money, and the overall strategy of the company, the better able they are to align their project with that strategy. IT folks will simply make better decisions because they will make those decisions in context with business needs. Focusing only on the technology might yield some impressive results but at a cost that might undermine the project’s business case.
-
Finally, many of these jobs pay a handsome salary. Executives expect to get their “money’s worth” from these folks.
That means they need to produce great products in a reasonable timeframe, helping the business increase revenue and profit. Strong technical skills are indeed required for people to get these jobs, but from my perspective, it’s the project management and other skills mentioned above that will help IT pros keep those jobs.
[trx_infobox style=”regular” closeable=”no” icon=”icon-desktop”]Learn more about IIL’s training in project management, IT, leadership, and more at www.iil.com. [/trx_infobox]
J. LeRoy Ward is a highly respected consultant and advisor to Global Fortune 500 Corporations and government agencies in the areas of project, program and portfolio management. With more than 38 years of government and private sector experience, LeRoy specializes in working with senior executives to understand their role in project and program sponsorship, governance, portfolio management and the strategic execution of projects and programs.