I never wanted to be a Project Manager. Well, at least not in the Information Technology world. Yet somehow, I landed in this role. Though I didn’t aspire to this, I viewed it as a challenge and decided to give it a go. I have held this position before, but as a hybrid role combined with other responsibilities – primarily Business Analysis.
Why did I go to the dark side?
As I already said, I didn’t want to become a Project Manager. When my current company recruited me, it was first as a Business Analyst. Being a BA has been my profession for the better part of the last 15 years. So why, oh why, did I go to the dark side? Honestly, I think I was a little bit bored. I have earned all the top Business Analysis certifications, and I’m always eager to learn new things and take on new challenges. In the last few assignments at my former company, I had fallen into a Scrum Master / Business Analyst hybrid role, and I enjoy being a leader who serves the team. So, when the recruiter asked if I would be interested in a Project Manager job, I thought it was worth entertaining. I wanted to take on new responsibilities, and being a full-time PM offers me that opportunity.
Why didn’t I want to become a Project Manager?
Well… I have done it before, but more traditionally. I didn’t enjoy the “command-and-control” approach to running a project – that’s why I prefer being a Scrum Master. However, these roles have largely converged since adopting agile practices, and most agile implementations are hybrid. Traditional project management requires you to direct people’s work. In contrast, agile project leadership requires you to support and serve your team by providing them with the tools they need and getting rid of anything blocking their progress. I figured I could change some hearts and minds to adopt more agile principles with the Project Manager job title.
What’s so hard about Project Management?
Project Management is challenging because you are responsible for delivering the project. You manage the budget, the resources, and the schedule. The iron triangle constrains you, and the scope and timeline inform your budget. I think this is a dumb approach, for the most part. I’m not saying that agile is a panacea or perfect for solving every problem, but it’s a more transparent and trusting way to build solutions. Project Managers always feel stress from changing requirements because they typically resist change in traditional (aka waterfall) projects. When change happens, you usually ask for more people, time, or money. And nobody likes to have to go begging for more to complete a project.
How is being a Project Manager different from a Scrum Master?
Project Managers have their heads on the block – ready to get chopped off should something go catastrophically wrong. Sadly, based on the data, this is often the case. Most traditional projects fail to deliver “on time, on budget, and with all scope” promised. It’s an abysmal situation for the project management profession. Agile addresses many of these issues because the work is incremental and iterative and follows principles of trust, transparency, and embracing change. Scrum Masters truly empower and enable their team to decide how to deliver small, valuable increments and trust them to self-manage to get the work done. Scrum Masters are almost the antithesis of traditional Project Managers, so seeing these positions combined presents a problem.
How do you navigate both waterfall and agile expectations?
There will always be a need for traditional and agile approaches in most organizations. Not every project is appropriate for agile, especially projects with physical components that need to happen in a particular sequence or when there is more known than there is unknown. Agile is appropriate for solving complex problems where less is known. The problem is that companies have traditional expectations. They can preach agile principles all day long. However, unless there is knowledge and understanding about what that means from the top-down, executives still expect to have all the details with dates and deliverables defined upfront. It’s unfortunate that waterfall is highly inflexible and doesn’t allow for change because its cost is so high in traditional projects. The best thing you can do is educate any stakeholders who don’t understand your approach. Explain how the iron triangle is flipped upside down when using agile. When being agile, time and budget are fixed while the scope is variable; this is a complicated concept for some because they’re used to knowing everything at the beginning of a project.
What do you do when problems happen (and they always do)?
You will inevitably encounter problems as a Project Manager. One of the essential skills of a PM is solving problems. In my mind, the key is to raise the issues early and address them as quickly as possible. It’s also crucial to be honest and transparent about problems because they will eventually come back to bite you if you don’t. If you’re unable to resolve issues quickly, enlist your leader and transfer the ownership to them, if appropriate. My advice is to deal with problems before they are too severe because the longer you wait to deal with them, the worse the impact is.
As a consultant with a contract, how do you deal with change?
Change is tricky. I’m a consultant, so my role as a Project Manager for a client means that I typically (unfortunately) have a fixed statement of work, with a specific list of scope items or deliverables and a defined timeline and budget. Sounds waterfall, right? Well, it is; this requires some finesse in dealing with clients. The key is to communicate your findings immediately as you learn new information. If something comes up that wasn’t in the original scope, you will need to either:
- Ask for additional money, time, or resources, or
- Give something up to get something new. It’s not always a pleasant task, but if you communicate along the way, and the change is not a surprise, it can work in your favor.
How do you tailor in an organization with standards?
Standards are about conformance and compliance; they are supposed to bring consistency and predictability to project delivery. Unfortunately, they can also be rigid, time-consuming, and wasteful when their use does not provide meaningful value. Traditional organizations, especially larger, enterprise-size companies, are more likely to have these types of project requirements. I think of standards as unnecessary overhead. Fortunately, the Project Management Institute® has come to its senses, and in the latest version of the PMBOK®, the guidance is much less prescriptive and rigid. Their new recommendation is to choose the processes and tools that make sense to you to deliver value to your customers. I love this. When you have tools in your toolbox and know how to use them, you can pick the best ones to get the job done in the best possible way. However, you might be stuck if you’re required to “check the box” by using standards. I would argue that you should question the status quo and ask “why” a standard is needed. If it doesn’t provide value, don’t do it.
What about PMOs?
Project Management Offices (aka PMOs) are, in my opinion, going the way of the dinosaur. A PMO exists to apply governance to company standards. They use the same rules and requirements for every project, no matter whether it makes sense; this slows work down with unnecessary approvals and oversight, increasing overhead costs without providing tangible benefits, such as a high-quality or a more innovative product.
How should you manage risk in a hybrid environment?
Risk will be a factor whether you are agile or waterfall, a Project Manager, or a Business Analyst. I see risk as everyone’s responsibility for identifying potential problems when one sees them. That said, the PM is the primary person for tracking risks and planning how to deal with them should they become a reality. In a traditional environment, this would likely exist in a risk register, with probability and impact scores used to rank each item’s risks and mitigation plans. In an agile world, you handle risks a bit differently; they are dealt with as early in the project as possible to get them out of the way and ensure project delivery is even possible. Risks are managed as items in a product backlog or a separate document – it’s up to you to decide based on your preference and your organization’s requirements.
So, did I make the right decision?
The jury is still out on whether I made a good decision to become a full-time Project Manager. The work is challenging, indeed, but it is also stressful. I feel the burden or responsibility for delivering the project and supporting the needs of the people on my team. I have dealt with multiple complex challenges, particularly people, that were unpleasant to resolve. However, I feel that my ability to deal with conflict, address things head-on, and build a strong team has grown. Regardless of how I execute a project, each one teaches me new lessons and makes me a more valuable leader in my organization. Irrespective of whether this experiment remains a good career choice for me, I will value the experience I gained and the people I led.
No from a different perspective is ON