5 Project Management Pitfalls to Avoid in the Tech Industry

Managing Projects in the World of Tech

I’ll be honest. While project management has fundamental skills and responsibilities that encompass any industry, I wouldn’t change industries for the world. The tech industry offers a wellspring of additional opportunities for unparallelled experience in cutting-edge fields of knowledge.

With a background in project management for digital marketing, software, and web projects, I’ve not only learned how to manage projects — I’ve learned about hundreds of unique integrations, platforms, and methods of team efficiency management.

My background has offered a few trends, however, that I see project managers (myself included) missing in their overall workflow that either hinder the team or the overall project. While there are a billion ways a project can go wrong (most of them highly customizable by project), I’ve narrowed my list down into 5 major issues project managers are susceptible to along with potential solutions.

1. Missed cross-team collaboration

This is an easy one to forget. With siloed teams across both small or large companies, it’s easy to forget that a simple conversation between a developer and a marketing consultant, for example, might make the difference between a shippable client-ready feature or one that needs to go all the way back to the drawing board. In this industry, there are many moving parts, and team members touching the project work differently, ask different questions, and need information communicated to them that will help solve their assignments to the best of their ability.

Easy solution? Every time a project changes hands — from design to content, from development to QA — ensure that those parties have a quick handoff, preferably in-person or at least via video chat, to ensure all questions are answered and the project can continue on its way.

The PM on the project should properly document this interaction, or request that the team documents it for them.

2. Scope change woes

The illustrious scope change. In Agile management, the scope is always the easiest option for change, with timeline and budget often being the factors that clients resoundingly do NOT want to change. This considered, if there are significant scope changes that either shift other prioritized items down in the process, or derail existing initiatives, many project managers aren’t sure how to either circumvent this or properly and tactfully warn the client of the ramifications.

Here are a few tips to ask yourself when dealing with scope change:

• How significant is the scope change
  If it removes a substantial number of other feature requests that were imperative for the project, indicate this to the Product Owner or the client.
• Will the scope change affect timeline?
  While scope change has the potential to aid timeline, if nothing is removed from existing requirements, it needs to be indicated to the client/PO that it will impact the timeline.
• Is the scope change insignificant?
  Many times, with smaller projects, I have clients asking for minor changes that are “technically” scope changes, but offer little significance to the timeline or budget. While this is tricky, ask your PO or internal stakeholder whether these requests are easily a win — you’re offering the client a little extra while also saving the scope change conversation for the items that are more significant.
  
  The last thing you want is to “nickel and dime” the client throughout the process and make them feel that every little change or request will add more to the budget. This issue is significantly heightened in the Waterfall approach, lending to the fact that the scope is supposed to be planned out ahead of time and static through the process. If you’re Agile (at least somewhat), and your client is on board, you can always re-prioritize and discuss other feature requests that are less important and schedule them for a future phase.
• Can it be addressed later or does it affect existing system build?
  Another great approach — and developers LOVE this one! — is whether the scope change can be addressed later, or if it should be addressed now. If the request is unrelated to how the existing APIs, integrations, or systems are being built, it’s an easy solution to hold off on that request until future phases in the project. It prevents the developers, in particular, from having to do a whole restart on systems they’ve already begun building and prevents delays in work completion due to discovery and research on the estimate and statement of work involved in the scope change.
  
  And sometimes, on the other side of the coin, the change request does need to be addressed immediately, in the case that the existing system will need to be built to account for this request later.

3. Outstanding Issues

One problem with the Agile approach I’ve noticed is in the misuse of the idea of the MVP — minimum viable product. While the concept is sound — deliver the smallest functioning feature to the client for review — sometimes that MVP becomes a half-baked solution for lack of capacity. This can ultimately lead into small pieces of a project being completed, but a variety of items left unsolved or not completed.

In order to prevent this, it’s important to have your backlog of tasks or deliverables fully built out ahead of time, before you determine what the MVP release might be. This will increase awareness of outlying items that aren’t completed. If you begin creating MVP tasks just to get something shipped to the client under extreme duress, you will find that your projects have a ton of loose ends at the end, and the timeline can be drastically derailed as you tie them all up.

In general, PMs of web and digital marketing teams should ideally agree on the MVP releases and have the time needed to complete everything in one project at a time. A Kanban board is a great method to ensuring that teams understand working on one item at a time.

4. The definition of “done”

The topic of outstanding issues above leads perfectly into my next issue — the definition of DONE! If team members aren’t sure what the agreed definition of done is, you will have a bloated loop of internal review and revisions before it ever reaches the client. Or worse — it’s sent to the client with blatant errors.

The best solution is not the easiest. Ideally, for web and software projects, you will have a designated business analyst or PO to establish acceptance criteria that your team can cross-reference before claiming something is done. It’s hard to say it’s completed if it doesn’t meet original criteria that’s been documented.

If your teams are not quite that “agile,” my best solution is to ensure that the workflow for team members reviewing their own work is clear, whether that is a templated worksheet or checklist used before sending you their work, or a task list with the full QA list of requirements included.

Unfortunately, the job description of “Project Manager” often becomes the catch-all for defining features that are done, so if that is you, BLESS you — take a deep breath, turn off your email, and review one thing at a time with a fine-toothed comb.

5. Team motivation

While the role of project manager is considered typically deliverable-driven, cold, calculated, and sometimes micromanaging, I tend to believe that leadership can be attained and deliverables can be met through vision and overall positive motivation. How well do you know your team? How well do you know if a team member prefers information relayed via email and also in-person to reiterate? While your main priorities should be the project efficiency and success, don’t get blinders on that prevent you from motivating your team in inspirational and positive ways.

This can look like researching new means of tracking workload, having lunch learning sessions to encourage new trends in the industry that you’ll be using in your projects, or something else — get creative! In all, don’t let the project run you and your team. YOU run the project. Guide the team with the overall goals in mind and motivate them to have pride in their work and its quality.

I could continue, but this is a good start. If you have any other items you think need to be added to this list, we’d love to hear about it.

Originally published at reusserdesign.com.