Author Archives: admin

Big Data: The Promise and the Peril

by

Last night, Women in Technology hosted an amazing panel on Big Data for their monthly WIT.Connect. Carol Hayes (Navy Federal Credit Union), Carrie Cordero (Georgetown University), Kim Garner (Neuster Advisory Services Group), Rashmi Mathur (IBM Global Business Services), and Stacey Halota (Graham Holdings Company) joined moderator, Susan Gibson (ODNI) for a discussion on the promise and perils of big data. I’ve compiled my notes to share with you.

IMG_1235

How Do we Define “Big Data?”

The first stop in the conversation was for the panel to define “big data.” Carol provided us with a brief history of the term, starting with the 1997 use by a group of NASA scientists who primarily were referring to memory & disk space issues. The term was further legitimized in 2014 when it was added to the Merriam-Webster and Oxford dictionaries. This usually requires at least 10 years of use, which alludes to even earlier usage. The panel definition refered to the 4 Vs – volume, variety, velocity & veracity. UC Berkeley researchers are now pushing to include elements of analytics & security.

Does Big Data Live Up to the Hype/Promise?

Much has changed about data over the years. Not only have we seen significant increases in the volumes of data, about 80% of big data is unstructured. Historically, data has been very silo-ed. The struggle for most businesses is figuring out how to use the data to make business decisions. The goal for many is to form a 360 degree view of the customer.  Technology is constantly improving to help tackle this challenge.  Some of the specific use cases discussed included fraud detection and marketing.

This week’s news brought us word of IBM’s $2.6 billion acquisition of Truven Health.  Susan wondered if investments of this size are worth it. Rashmi challenged us to look beyond a single investment and focus on the broader IBM initiative to use data to improve health, and view this acquisition as part of a broader healthcare ecosystem.

On the topic of whether small businesses get left out of the big data conversation, we were reminded that all businesses have very valuable data. Leveraging the data you have with 3rd party data can significantly increase the data value. For small businesses, the bigger challenge tends to be having the internal resources available to drive the business questions and analysis.

What About the Perils? Privacy? Security?

In thinking about the perils, privacy & security of big data, we need to consider it from the point of housing, aggregating & sharing it. Stacey challenged us to answer the question “how much data are we deleting” on a regular basis. She recommends at least having an annual discussion. Before that, you should have already done your data inventory to document what you have & why you have it. Stacey cautions us to be straightforward in thinking about the data you should (or shouldn’t) have. For those working with their client’s data, it all begins with the business question. Once you know what the business goal is, you can decide what data you need. You will need to consider the balance of risk, opportunity and cost.

The collection of data outpaces laws & compliance. This has resulted in a decade of breaches. Protecting information is a governance issues not a technical issues. Governance should drive protection. The enhancements in big data technology has resulted in newer technology including the security measures from the beginning (versus adding it as an afterthought).

It’s agreed that privacy & security issues impact businesses of all sizes. Unfortunately, the smaller organizations take on higher risk as a result of limited structure & longevity. It is much harder for a small business to survive a hit to their reputation breaches can cause. We need to ensure that employees get the education needed to handle data. There should be no distinction between programming and secure programming. Ideally, security becomes so engrained in our business process that it just happens without the need for separate functions.

The panel recommended these 5 actions for getting ahead of compliance issues:

  1. Review the California recommendations on breach of personal information
  2. Review the ISO 27001 information security standards
  3. Establish an Incident Response Plan that outlines point of contacts, forensic partner(s), lawyer, etc
  4. Have a plan & test it
    • there are incident response simulation consultants to assist you
    • the general process is to answer a list of questions & receive checklist of legal & custom actions to take
  5. Share incident information with other companies within the industry

Inherent in housing, aggregating, analyzing and sharing data is risk. How much risk is too much? That will depend on the nature of the organization and the data. IBM has the business group respond to a simple questionnaire that helps drive that assessment during the initial phases of new projects.

While the discussion touched on global compliance for companies, this is currently in a bit of flux at the moment. The Safe Harbor framework that allowed US companies to self-certify that they handle data in a way consistent with the EU requirements was recently challenged. Privacy Shield is the new framework being developed to outline the new requirements. Global companies should be watching these decisions closely.

Where Will the Future Take Us?

  • Tell me before it happens – Companies are leveraging historical data to predict the future. More often, companies want to be told what will happen, before it happens. Insights will get crisper as we begin to hone in on relevance.
  • Data journalism – the ability to tell stories with data is the wave of the future.
  • Natural language and machine learning will make people smarter. It’s all about enablement.
  • Threat intelligence – the sharing of information becomes more critical.
  • Regulatory compliance – inequality and accountability of government versus private sector will converge.

Any Parting Words of Advice?

The consensus is that big data yields plenty of opportunity. It’s one of the few industries where there are plenty of educational opportunities, and negative unemployment. “Any career with ‘data’ is good.” Be sure to look at degrees and certifications, but those aren’t required. Natural curiosity can nicely lend itself to the human side to data analytics. Deliver “the art of the science.”

One final Afterthought

No good conversation about big data occurs without having a mention of veracity of data. Long before modeling or analysis begins, significant time is spent on ensuring good data exists. Thought and care needs to go into cleaning the data, filling in missing data, ensuring the data makes sense.

4 Considerations When Choosing Project Management Tools

by

Project Managers tend to be very opinionated on the “right” PM tools to use. This discussion, and interview question has always frustrated me. I strongly believe that it doesn’t matter what tool you as the Project Manager prefers, you should be able to adapt to whatever tools work best for the organization and your customer. If you Google “recommended project management tools” or “the best project management tools” you can between 34 million and 125 million results. In my experience, there are four key considerations I use for the basis of deciding which tools will work best.

Which-direction-Fotolia_50558549_XS-300x221KISS

Keep it Simple! The least common denominator is usually the best option. Tons of fancy features aren’t generally very helpful. Often times you pay for the luxury of having those available. Apply the 80/20 rule to your evaluation process – 80% of of your needs will be fulfilled by 20% of the features & functionality in most project management tools.

Audience

Who is your audience? The tools you leverage with your project team or for your own planning will probably be different than those you use with broader stakeholders. I have found that simple tools are often best. While I can develop a complex gantt chart, and will sometimes do so for my own planning, I find basic word-processing & spreadsheet applications are easier for less technical (or PM focused) audiences.

Proximity

Is your audience within or external to your organization or team? Often times you need to deliver project status and meeting notes to an audience with internal and external participants. These are more static update tools, rather than interactive. These tend to capture status, action items, changes, decisions, etc. This is the right tool for conveying priority or tasks to another team within your organization where you may share resources. Additionally, you will want to figure out how to make project artifacts easily accessible. This may be through an intranet for internal access only, or a collaborative/extranet solution.

If your audience is located in your same office, I would highly recommend using tools like white boarding and sticky notes to brainstorm and organize. Recent studies (here’s Inc’s write-up) have shown that leveraging less technical tools improves creativity and brain power.

Feasibility

This consideration encompasses cost and availability. Sometimes your decision is just made for you. If you are running your project budget or organization very lean, you’ll want to leverage open source or free software. Alternatively, if your organization has negotiated a software licensing deal that gives you access to specific tools, it may make the most sense just to use what’s available.

At the end of the day, don’t overthink your tool selection. Decide what your critical goals are, and find the tools that meet them. There are significant advances in project management tools that provide plenty of options. Not all of them are right for all projects, teams or organizations. Sometimes it best to get everyone in the room, using the most basic tools of all.

My Take on the Data & Women DC Inaugural Event

by

It’s been a while since I wrote about women in tech, but I attended the Data + Women DC Inaugural Event last night, hosted by CHIEF (check out their blog for their monthly events) and was really inspired by what I saw and heard. In some ways the format was like all other meetups, networking followed by a program, but this group did something a little bit different by splitting into smaller groups for more intimate discussions. It was definitely easier to get to know people, and as one person in my group said “maybe all meetups need to treat each event like it’s an inaugural one, and give everyone a smaller forum to be heard.” I tend to agree.

Unfortunately, or given the aforementioned feedback, fortunately, I was coming from another appointment so missed the networking. I caught part of the panel discussion and then all of the small group discussion. We hit on quite a few pieces of advice or considerations that I wanted to share.

Brag!

One of the most critical points made in response to the question about what you and/or your company can do to help advance women was about bragging. Often we are uncomfortable with other people bragging about our work, especially if it’s unexpected. It’s important to promote the work you do, and if you’re not comfortable doing that, then maybe having your friends and colleagues do it for you, will help make it more comfortable. One participant said she was going to take that recommendation back to her corporate lean in circle.

Emotion & Passion

We definitely touched on not allowing your emotions get in the way of your passion (or lack their of). Several participants shared their experience creating a goal to accomplish X to prove you could, then realizing part of the way that you didn’t want/like this. In the same vane, if something isn’t working for you in your current role or with your current company, it’s within your right to fix it. And if your company isn’t willing it work with you, then it’s time to fulfill that somewhere else.

Confidence & Competence

We had a fairly extensive conversation about women’s confidence & perceived competence. There have been many studies that show men interview for potential (what they believe they can do) and women interview for performance (what they know they can do). While the overall consensus was that we wanted to be true to who were are, and what are capabilities are, but still acknowledge what you can do. Some discussion occurred around how frustrating it is to work with people who say “they can do everything”, but in reality can only do some portion of it. This conversation brought to mind the differences I see in male and female developers. Many male developers I know will say they have experience in language a, b, c and therefore have learned the programming methodologies and frameworks and feel they can do languages d, e and f. Female developers that I know tend to put more weight on what they have done (i.e. language a, b, c). I hope female developers will become comfortable enough to take the same stance as men, extrapolating from their experiences to speculate what they can do.

Inherent Bias in Open Source and Software Language Naming

Our group shared some interesting experiences with the open source apps and software language naming conventions. One participant was recently using an app and came across very male gendered language in the examples and documentation. In pushing the issue on social media, she was able to get some changes made, but no clear alternatives to the problem. Another participant introduced the topic of software languages named for females tend to use very comfortable, personal first names (Ada, Ruby, Julia). That’s rather interesting when you apply the aggressive “wrangling”, “manipulating” verbs towards it.  I can’t say that I had observed either of these first hand. I wonder if I just don’t notice.

I had a great time connecting with my small group. I hope I represented our conversation well. And I hope to see everyone again.

The Myth of the Project Plan

by

 

The Project Management Institute Project Management Book of Knowledge defines a “project plan as a formal, approved document used to guide project execution and project control.” It further specifies that “it should be used to document approved scope, cost, and schedule baselines.” In my experience, a project plan is treated heavy on the “formal” and “approved” and light on the “baseline.” I think the process of approval gives the perception of longevity on the life of the plan. This minimizes the impact of the project plan as a baseline. Unfortunately this misunderstanding causes many complaints about project delays and delivery.

I was struck by this Computer Weekly quote when I conducted a google search for “project plan”: “[It] is one of the most misunderstood terms in project management. It is a set of living documents that can be expected to change over the life of the project.” This is polar opposite to how I have seen the project plan treated. The project plan is usually created at the beginning of the project, based on a statement of work, with fairly limited information. Even in cases where all stakeholders understand that the project scope is fluid, the project plan is expected at the beginning of the project and is used for making time-specific business decisions (training, user acceptance testing, etc).

Historically this has resulted in project managers padding their project plans with additional time so that the project is guaranteed to come in on time. Alternatively, the project plan isn’t padded, but issues of either scope creep, or scope reduction occur. In all cases, decisions are being made to meet a deadline, often selected artificially, which only aligns to the information available at the beginning of the project. There is no consideration to the fluidity of project implementation and information availability.

It would alleviate quite a few problems in project delivery & success if we chose to leverage the project plan as a living, breathing document. As time progresses, and additional details are obtained, the project plan should be updated. As a project team, we would be in a much better position to make decisions, and set more realistic deadlines as we get into the details and work through the development. Furthermore, sharing regular status and having constructive conversations about the state of a project and the next steps result in a more successful deployment. 

 

 

3 Pitfalls with Allowing Technical Teams to Engage Directly with Clients

by

We all inherently know that our best options are to always to go directly to a source, whatever or whomever that is. In a recent post, I advocated for allowing your project team to engage directly with customers. While I strongly believe this allows you to deliver a better experience, I do think there are a few pitfalls to avoid.

bomb_clip_art_10552 1) Be careful about the “shoot from the hip” responses – Often times in design or business discussions an inquiry will ask “how long?”, “how much?” and it is common for people to “shoot from the hip” and give an answer. There must be a structured way to balance these casual conversations, with the reality of the project status, plan, resources, investment. Otherwise, you will get stuck in the never-ending project and perpetual scope creep.

2) Balance gut estimates with discovery – Everyone is in a rush to understand how long it will take to build this product, feature or system. You need to be able to leverage your knowledge of having done similar applications, with the project discovery you need to do to understand this particular project. Too often I’ve been caught in situations where I had to explain that while a team member said they had done something similar in 10 hours, this particular implementation was going to 40. At initial thought, this seems excessive, as compared to the similar project. However, once you start talking about all the additional project management, testing and discovery required for this one versus that other one, it becomes more palatable. Make sure you vet gut estimates with actual requirements and customer needs.

3) Avoid detours – A huge risk to allowing project teams to engage with customers directly is subtle permission this introduces to go directly to the project team. I’ve seen customers who will stop engaging with ticketing systems in lieu of going directly to project teams. This introduces quite a few disruptions to the process. First it makes tracking and accountability difficult as inquiries aren’t going into a central system. Second, it can overwhelm project team members as they try to balance assigned work with the customer engagement. The project team will sometimes feel that they “have to respond.” The project manager or customer success manager needs to step in and manage the process. The team needs to make sure that they are being responsive, but doing it in a way that addresses the customer priorities, and keeps the customer involved in making those decisions.

As I’ve mentioned before, I’m a huge advocate for engaging project teams with customers. This is not a free for all. There should be a structure and methodology, with appropriate accountability and check points to adjust for the changing environments.

4 Ways Project Managers Deliver Quantifiable Value

by

It is sometimes hard to understand the quantifiable value that strong, technical project managers bring to organizations. I would go one step further and say that some people question the value (of any kind) that project managers bring to the table. Like many in operational roles, project managers are blamed for project challenges, but are often overlooked after project successes.

I searched Google for articles on how project managers deliver quantifiable value. Mostly I found articles that were more conceptual in nature about why you need a project manager or project management office (PMO) or how to get the most value out of your PMs. I didn’t find tangible ways project managers actually improve the bottom line of the organization. In an age where every function needs to be delivering quantifiable value, I was a bit surprised. I know that strong, technical project managers are invaluable to organizations, and worth every penny of their cost.

Project managers deliver Quantifiable Business Value by:

  • Reducing busy work & obstacles for the project team – It has been proven that focused, dedicated time improves the quality and reduces delivery time of technical solutions. A strong PM will handle the busy work, allowing the team to do just that. Cost savings:  Reduced hours worked for project delivery & reduced hours of non-billable rework.
  • Managing the analysis & artifacts – This is an often overlooked function of a PM. A good PM will understand the business requirements and can help facilitate troubleshooting & testing. Additionally, the PM will also be able to write & manage the artifacts (project plans, requirements, implementation documentation), which become most critical during testing & supporting the development post-implementation. Cost savings: Reduced costs for testing, support & maintenance and facilitation of support functions away from high cost developers to less expensive support resources.
  • Reducing risk – A project manager will feel comfortable managing the scope, and making decisions. The PM is willing to have those tough conversations for prioritization. Cost savings: Reduction or elimination of unanticipated costs associated with scope creep. Additional cost savings come from keeping project on schedule.
  • Improving project delivery &  allows for new work – Lastly, and arguably most important, a good PM will deliver! Often organizations get bogged down by lack of prioritization resulting in all resources making their own decisions. This chaos slows the progress of project delivery. For all the reasons outlined above, a PM will delivery projects, which will open the window for new work from customers. Incremental revenue: When PMs deliver, customers deliver too! In this case, it’s in the form of new work.

Don’t under estimate the power of a strong, technical project manager for the success of your business. While you may wonder if you can afford the cost, I would argue that a PM can pay for themselves in what he/she delivers in return.

 

Use Cases & Technological Investment: The Technology Chicken & Egg?

by

In traditional manufacturing, it’s unheard of to purchase production grade equipment without knowing exactly what it will be used for, and more importantly how the significant cost will be recuperated. However, I have seen it first hand that this isn’t always the case with technological investments. It is not uncommon to make a significant investment in a software or hardware solution without fully understanding the business use case.

Courtesy of iterated-reality.com

Courtesy of iterated-reality.com

A September 2015 blog post by Jarvis on Technological Trends that Impress VCs emphasizes leveraging your business use case to make purchasing decisions. Similar themes include not going extravagant until necessary, improvising as you scale, and ultimately not making a purchasing decision merely because the technology is the best, but rather choose the best solution for your business.

A Workspace blog post “Investing in new technology – right for my business“, written by Mark Sharman, discusses some of these same points. Mark raises the concern of being carried away by all the technology bells and whistles, so strongly recommends having a business use case or cost/benefit analysis to fall back on. Additionally, the “real cost of the investment” needs to be fully recognized, inclusive of delays and opportunity costs of not doing something else. That said, Mark reminded us that surviving in business requires keeping pace with change, but thriving in business requires leading the change.

This effectively highlights the conundrum of use cases versus technology investment. If you make the investment to stay on top of changes in technology, will the use cases come? Or if you define the use cases, will you be leading the pack but putting yourself at risk?

Example 1

In one example I’ve seen, the CTO had implemented a massive initiative to move everything to the cloud. At the time, I oversaw highly critical, back office processes. While we had been in the process of reinventing our systems, it didn’t make a lot of sense for us to move into the cloud. It would have added extra layers and complexity, and moved us away from our data sources. However, the implication of not complying to the blanket initiative were large enough that I chose to define a solution where we would be able to move components to the cloud. After I left my position, a former employee of mine, who was still involved, asked why I had designed the system for the cloud. To him, it didn’t make any sense. I agreed, but explained the nature of the political decision I reacted too.

Moral of the story: Just because we can, doesn’t mean we should.

Example 2

In another example, I was working with a company to implement a very complex software solution. They made significant investment in this solution, and worked closely with us during the development and validation phases of the project. There were two project phases that each took 5-6 months to complete. After the implementation was complete, we didn’t hear anything else about it for another ~6 months. At this time, the company asked for a in-depth, technical and business training working through the business requirements through to the technical implementation. During that training, I was told that the team was still working on the use cases for how they wanted to leverage the solution.

It seemed to me that the significant investment in capital and time would have encouraged the need for a business use case before implementation, but that wasn’t the case. Should the company have made this investment without the use case? They were at the cutting edge of this solution, and were able to influence the process by taking a very hands-on approach.

Moral of the story: Sometimes it’s better to be first and influence the solution, than worry about exactly how you are going to use it.

I was talking to my mentor and friend, Dave Shuman, yesterday about this. He challenged that some of the newer, trending technologies lend themselves to investment first, then defining the use cases. The low barriers to entry from a cost and implementation perspective allows for that buy first, define later approach. Lean Startup development methodologies also lend themselves to building in incremental blocks, then iterating until you find the “right” product fit for your customer.

Final Thoughts

So whether you define your use case first, or whether you invest in technology first, you do need to figure out that sweet spot to getting to your return on investment. We all know how well it turns out if you spend all your money and have nothing to show for it.

3 Considerations When Managing Globally Diverse Project Teams

by

Global project teams happen more often than not these days making it no longer feasible to get everyone in a room to facilitate a project. As a Project Manager & leader for both global team members and global customer teams, I’ve experienced the added complexity of this on my projects.

A LiquidPlanner blog post by Tim Clark from October 2013 “7 Tips for Managing a Global Project Teams” highlights time zones, cultural, religious, and sociological differences. Mr. Clark also recommends staying on top of advances in software solutions to simplify the process.

Global Teams

My Experience with Global Teams

Inc. published “5 Tips to Manage a Team Across Multiple Time Zones” by Will Yakowicz in July 2014, which also had very applicable information. Mr. Yakowicz reminded us that we can’t work 24 hours/7 days a week, emphasizing a consistent schedule. He also encouraged us to leverage the latest technology, invest in airfare to facilitate team cohesion while also recognizing that we must be extra aware of those people who aren’t sitting in the same room as us.

In my experience, there are a few additional key considerations for successfully managing global teams.

  • Be Flexible – As the project manager, it was my responsible to facilitate the project. Some things do just get lost in translation over email, and it’s necessary to have a phone or video session. Unfortunately, it’s not all about me, therefore it can’t be all about my time zone. I often had calls in the early morning or late night to coordinate with Europe (EMEA) or Asia (APAC) as required.
  • Be Available – When you have remote teams, it is imperative for each team member to be more communicative than would be required if everyone was in the same place. I can’t hover at someone’s cubicle when they are based in Ireland, but I can make myself as available as possible, as well as encourage each of my team members to do the same, on any mediums used by the respective regions.
  •  Diligently Break Down Barriers – Communication is hard. It’s even harder when you’ve never met a person, other than via email or phone. More often than not, when you are driven to a phone call it’s to resolve an issue. I encourage you to take the time to introduce yourself and chat. By learning the personality traits, and what drives your team, you will be better able to motivate them.

Managing global teams is difficult. The pace of project delivery, technological advances and life adds to the complexity. However, it is the new normal. We’ll need to step up our game to learn to do it well.

Professional Services Leadership – 3 Reasons to Engage your Project Team with your Clients

by

There has been a long running discussion in professional service organizations about whether the technical project team members should be engaged with clients, or whether they should be sheltered from clients often under the guise of allowing them to focus on their task list. In my experience as a Project Manager and Customer Success Manager, I’ve found that allowing them to engage with clients directly streamlined project communication, and expedited the “right” development.

An April 2012 Inc article “The New Rules of Customer Engagement” by Wendy Lea outlines the new customer engagement paradigm. The focus has shifted away from single, often isolated touch-points to a much more integrated, customer-focused, results-driven experience. This particular article is geared towards engagement in social media, it drives home the point that customer service is no longer seen as just part of the sales process. Every conversation that happens, in any venue must be driven toward customer resolution.

https://s3.amazonaws.com/webmobi/Development/websitepics/customer.jpg

Web Mobi Customer picture

A October 2014 Survey Monkey blog post discusses 5 crucial reasons to engage your customer service and product teams as a means to deliver consistently great customer service. It argues that product project teams don’t spend enough time with marketing or customer service to fully understand customer issues and sentiments.

Overall, I think we can agree that being fully engaged with our customers, including fully understanding customer issues and sentiments, is imperative to our business success.  Even further, it is a given that our organization needs to be fully engaged across internal teams. I argue that the technical project teams also need to engage with customers directly. Three critical reasons include:

  1. It streamlines customer communication – When a technical resource needs to make decisions based on business requirements, it can be significantly easier to communicate a question directly to the customer. Critical details often get lost in translation when the technical resource communicates to a project manager, who then translates it to the business user.
  2. It simplifies the project management role – By allowing the direct communication, the requirement for the project manager to be technical becomes minimized. The PM should still understand the technology, but their focus becomes more of a facilitator and a remover of obstacles.
  3. It more closely aligns the customer to the technical team – When the technical project team engages with the customer, and visa versa, each begins to see behind the curtain. This allows each side to more fully appreciate the challenges and opportunities that exist. If the customer never experiences the technical process, or the technical team never experiences the business requirements, you lose the epiphany moments that come from truly solving the customer’s problem rather than more superficial symptoms.

I have seen great success with having my technical teams engage with customers directly. It becomes my role to manage the scope, prioritize the follow ups and generally keep everything on track. I step in to facilitate conversation or remove barriers to success, but don’t get in the way of progress. I challenge each of you to review your engagement model and figure out how to incorporate customer-technical resource communication.

Professional Services Organizations: Do your Project Managers Create Work or Remove Obstacles?

by

I’ve had several conversations lately with software developers or business management regarding project managers, and whether they create work or remove obstacles. As a project manager myself, I’ve felt that removing obstacles and allowing resources to focus on the tasks at hand is one of my top priorities.

In researching this issue, I found a September 2005 article by Scott Berkun “The Art of Project Management: How to Make Things Happen” that highlights that the ability for people to move project forward (AKA remove obstacles) is a skill that some people have, but others do not. Berkun proposes that this skill comes down to knowing how to be a catalyst in many situations, while also having the courage to do it. Additionally, projects move forward more when: prioritization occurs; “no” is accepted and appreciated; open & honest communication occurs; the critical path is known and the PM is relentless & savvy.

PM Technical Skill to Execution Matrix

PM Technical Skill to Execution Matrix

A more recent article published March 16, 2015 in MITSloan Management Review by Alexander Laufer, Edward Hoffman, Jeffrey Russell & W. Scott Cameron “What Successful Project Managers Do” emphasizes the organizational responsibility required to allow project managers to be flexible. This research article states that project managers need to: develop collaboration; integrate planning & review with learning; prevent major disruptions and maintain forward momentum. This ultimately results in a more fluid, adaptive project.

As projects have become significantly more technical in nature, the divide between project managers who create work or remove obstacles has become more pronounced. Technical implementation projects push this even further. As project leaders, we need to recognize the impact of technical skill and the too many active projects on ability to manage a project to its completion. There are 4 combinations on the technical skill to execution matrix:

  • Technical but Overworked – These project managers have the skill, but are not capable of removing obstacles because there are too many other projects on her plate.
  • Technical & Actionable – These are the technical project managers that are able to remove obstacles for their team. Often these resources get overlooked by the project team as they are seen as just doing their job.
  • Non-Technical & Actionable – These resources tend to be PMI certified so know the mechanics of managing a project, are able to remove obstacles without needing to fully understand the technical pieces.
  • Non-Technical & Overworked – These project managers also tend to be PMI certified so know the mechanics, but are overworked so they can’t focus on removing obstacles. Ultimately these pieces get pushed to project resources.

As a technical project manager, I have some bias about which quadrant the rockstars reside. However, there are some strong non-technical project managers who are able to successfully complete projects. This requires management support and a level of organizational prioritization that is really difficult.