Project Management Evolution: Startups vs. Enterprises

Startups play poker, big companies play chess.

This quote by Don Dodge, Developer Advocate at Google, encapsulates the difference between startup and enterprise for project managers.

Startups are playing a game of probabilities. As with poker players, the best ones consistently win, but will at times lose to amateurs. In startup project management, you need great execution, but the truth is that even the best entrepreneurs can fail. As with chess, an enterprise project management system needs to be much more strategic, plan two steps ahead, and take on less risk.

It’s Not All Black and White

One caveat before we dive into this topic is that there are all kinds of companies. Can you call a company with 100 employees a startup anymore? What if it grows to 200 or 300 employees? Sometimes Uber is still called a startup in the media, however, Uber now has 12,000 employees. Another distinction is that a startup started by undergraduates is very different from one started by serial entrepreneurs with 20+ years of professional experience who may have previously worked in the enterprise and have brought back the best practices from there to their startups.

Thus, there are many cases ranging between a co-located startup with 5 people and a multinational corporation with offices all around the world. While this article will mostly focus on two extremes, take all of it with a grain of salt and think critically about whether the takeaways apply to your specific situation.

Startup vs. Enterprise

With this caveat out of the way, let’s try to define the two extremes to lay some ground for our discussion. For the purposes of this article, the characteristics of a startup are:

• A co-located team (~1-50 employees) where you would typically know all of your colleagues by name.
• Roles are loosely defined.
• Co-founders are very active in making most of the decisions.
• Company is losing money and there isn’t a long runway left - survival is a major problem.

At the other end of the spectrum, an enterprise would look like this:

• Multiple departments and locations.
• You only know your direct colleagues well and interact with a handful of people from other departments.
• Everyone has clear responsibilities and hierarchies.
• The company might be public.
• Profitability and short-term survival is likely not a concern.

Startup Project Management

Project Manager ≈ Product Manager

In theory, project managers have substantially different responsibilities to product managers. However, in a startup setting the two roles usually become intertwined. If you are a project manager, startups are likely to give you many more duties outside of what you would traditionally do in an enterprise.

Opportunities for Startup Project Managers

Quick Decisions and Large Impact

In startup project management, it is quite easy to make important decisions as there are not a lot of dependencies in terms of processes, other teams, clients, etc. Something as important as hiring a new colleague, changing the homepage, adding new features or extending a deadline could be one meeting or Slack conversation away. This is empowering for a project manager and creates a sense of autonomy.

A startup is a good place to try out your ideas and grow professionally. You can try out a new project management tool that your friend told you they use in his company. How about moving from Scrum to Kanban? Whatever makes you deliver faster, replies the CEO. What do you think about implementing that new chatbot which allows querying your Google Analytics in natural language? You don’t need a developer for that, explains your CTO over lunch. In an enterprise, all of these would be separate, big, and long initiatives managed by a dedicated project manager.

Things Get Done Fast

The development life cycle in startups is much shorter than in enterprises. You could be ideating today and have something in production next week. There is not a lot of legacy code, so developers are not complaining that the codebase needs to be refactored and thus are able to deliver results rapidly. This allows you to be in a constant feedback loop with your clients and be truly agile.

Easy to Adapt or Pivot

The same speed of delivery and lack of dependencies allows a startup team to swiftly change course. A famous example is PayPal. In the first 15 months since its inception as a “cryptography for phones” solution, Paypal pivoted 5 times. The market for payments was changing fast and PayPal was able to outcompete eBay, which was developing its own payment solution called Billpoint. PayPal’s agility allowed it to have better traction with eBay buyers and sellers, eventually leading to eBay acquiring Paypal.

Fluid Processes

Usually, there aren’t many rigorous processes and procedures for how people within a startup operate. A lot of it is left to common sense and internal negotiation. This is one of the major reasons why the points mentioned above actually work, i.e. you can make decisions faster and don’t need countless sign-offs. Of course, it is inevitably a trade-off, which causes other problems down the line as we will see later in this article. However, for a startup, which is looking for a product-market fit and trying to outcompete better funded and bigger competitors, it is a reasonable trade-off to have.

Challenges for Project Managers in Startups

Responsibilities Are Not Fully Defined

A fluid process enables quick and intuitive decisions. This is smooth sailing when things go well, however, the flip side results in mistakes and a chaotic environment. Broken down, a process is essentially a checklist - what steps need to be taken for an outcome to be achieved. Processes usually come about as a result of some failure, when colleagues start blaming each other for not taking care of something and a company initiates the creation of a process to streamline decision making into clearly defined steps to reduce the risk of such problems occurring in the future.

For example, a new release has crashed a client’s website. Everyone in the company knew about the upcoming release, yet no one informed the client. Should the project manager or the key account manager have contacted the client’s development team? Should the CTO have been more proactive? After a heated discussion, the people involved agree that next time particular employees will be responsible for particular actions prior to release, to ensure this doesn’t happen again.

This example is a microcosm of how a startup evolves into a corporation. As complexity in a startup grows day by day, such decisions are made and ambiguity is removed from daily operations. However, until that state is reached many painful mistakes are usually made.

Weak Bargaining Power

As a project manager in a startup, you are more likely to engage in external negotiations. Co-founders might be taking you into later stage client meetings to represent the technical or the product side of the pitch. A lot of questions and new requirements might arise during that meeting and a project manager has to make sure to not agree on deliverables too soon. The co-founders might be anxious to win the potential client and agree to their conditions even during the meeting, not realizing fully the cost of the new backlog items. The client might be using the fact, that your startup does not have a long track record, to make you commit to more than you can reasonably deliver.

A project manager has to be able to push back and to ask for more time to evaluate the new requirements with the development team. Once you have at least rough estimates from the team, present them to the co-founders and have a discussion if still makes sense to agree to the new conditions of the deal.

Shortcuts Create Legacy Problems

In a startup, it is very easy to be in constant MVP mode. As a project manager, it is very tempting to push the development team to agree to tighter deadlines and take shortcuts for roadmap items. With the co-founders constantly on your back, it seems almost necessary. However, as the popular saying goes–with great power comes great responsibility. If you abuse this power, eventually your team will start running into legacy problems. And this doesn’t mean sometime in the future–you are likely to run into these while still in startup mode.

For example, let’s say that your company decides to create a product listing page. It has to have multiple filters to narrow down the results. It also has to have sorting options based on various attributes. The initial estimate is too big and you try to narrow down the required filters and sorting options. Eventually, it turns out that the majority of the estimate is the whole system - searching and returning the results. You ask if there is any way to deliver a simpler version faster. One developer suggests using a third-party solution with a monthly subscription. The other developers talk about dependency issues and legacy concerns. For you, it sounds perfect, because you get your MVP faster and later on the subscription can be canceled if you decide to scrap the project. The scrum master agrees to use the third-party solution only if they get a chance to rewrite the code if the project is not scrapped.

The reality though is that this agreement is almost never fulfilled unless the scrum master actually puts in a technical debt task in a later sprint and defends it when the time comes. If the initial feedback for the listing page is positive, the natural reaction for the project manager is to develop additional features since the MVP was only a test. 6 months later, you reach a point where adding new features becomes very costly, but refactoring is even more costly, and then there are other priorities that become more important and overshadow the initial intent.

False Positives

A false positive in the case of IT project management would be when your team develops an MVP and you take initial positive feedback as proof of product-market fit. It can happen even earlier in the process when your stakeholder tells you: “I’ve pitched our solution to the biggest client in our industry and they said they would definitely buy it from us.” You develop it, and then they don’t actually buy it from you.

False positives are a big challenge, but there is a way to mitigate them. Steve Cohn, Founder of Validately, suggests that you should validate demand for your solution. There are three signals that can help you:

1. Are your clients willing to spend or commit money even before you deliver the full solution? Getting a contract before delivering the solution is probably the best validation that you can get.
2. Are your clients willing to spend time with you on developing the solution? Time is money and everyone has an endless backlog of tasks. The more a client is actively engaging with you in figuring out the requirements, involving his other colleagues into the discussion, testing an MVP thoroughly and providing ample feedback, the more likely you are on the right path.
3. Are your clients willing to use their reputation to promote you? Whether it’s on social media, at a professional event or in any other form, when a client is promoting you, they are lending to you their reputation which validates their genuine interest.

Stakeholder Management

A project manager’s most important stakeholders in a startup are usually the co-founders. As we saw in the opportunities part, the co-founders can enable quick decision making based on common sense. However, the problem is that a lot of co-founders quite often rely on their instincts for decision making. That is especially true for co-founders who have worked in a particular industry as professionals of the field and have now decided to create an IT solution to solve a problem they themselves faced in their jobs.

Deep market knowledge is extremely useful for any startup, however, it cannot be solely relied on when creating a roadmap. The aspiration of most startups is to create a solution, which will scale internationally. Even if there are multiple companies in the same market, they will not necessarily go about solving their problems the same way. The co-founder might have intimate knowledge how his previous company did things, but that does not translate to knowledge about how other companies, especially in other countries, solved the same challenges.

Co-founders more often than not hold onto their convictions and need an independent project manager to counterbalance their views. It is a project manager’s job to educate the co-founders on the importance of data-driven decision making and agile development in the early stages of product discovery.

Project Management in Enterprise

Project Manager ≠ Product Manager

As a startup matures and becomes a big enterprise, the roles of different positions become more and more defined as the work becomes more specific. Even in an enterprise, there are cases where project managers and product managers overlap. However, the project manager tends to focus more on the operational aspects of a project, whereas the product manager is responsible for the execution.

Project Management Office (PMO)

As a company grows, their portfolio of projects grows with it. New project managers join and with them bring new project management tools and methodologies. Initially, things get a bit chaotic and a need for a project management office (PMO) arises. The PMO is concerned with the project management lifecycle and can either spread or enforce best practices across the whole company.

As a project manager in an enterprise, you will have to interface with a PMO. Each PMO is different, but of the things that you could face are:

• Filling out various forms for project initiation and closing.
• Submitting budgets for review.
• Providing regular progress updates.
• Getting sign-offs on milestones or various process steps.

For a project manager who is already doing a lot of planning and tracking, a lot of the PMO requirements might seem like needless red tape, especially if it starts slowing the project down. While this bureaucracy can be a source of frustration, a proactive project manager can minimize the overhead and even extract value for the project from the PMO:

• Engage the PMO early on to figure out the reporting requirements. These can then be matched to materials produced during project execution to save time.
• Be a process champion. Provide feedback to the PMO on how the processes can be changed to make the life of project managers easier. One of the main goals of the PMO is to help the product manager to be effective.
• Leverage the PMO for assistance when your project runs into problems. The PMO has a company-wide outlook of all projects and has experience in dealing with various problems or risks that arise during project execution. Utilize their knowledge to your advantage.

Opportunities for Project Managers in Enterprise

Credibility

The stability and long-term planning of enterprises show credibility to clients and partners. The people who want to engage with your company are looking for a good track record - that you are able to deliver on your promises and have a lot of experience in your area of expertise. This is one of the biggest advantages that an enterprise has over startups. It makes it easier to find new clients and partners.

This trust enables you to have more integration with the client. As a technology vendor you are enabling your customers and in turn, they might adjust their own roadmaps to your’s to be able to deliver new features as soon as possible. Such a relationship would be very hard for a startup to achieve as startups are very volatile and hard to trust.

Easier to Gather Requirements

An enterprise has a much bigger presence in the market compared to a startup. As a company grows, and the work becomes increasingly specific, more and more specialized professionals are being hired. At the same time, to maintain the vision, more and more seasoned top-level executives join the company. All these people bring enormous market insight, which is very easy for a project manager to access and utilize in gathering user requirements.

This can be a great advantage for PM’s personal development too. Having a large number of contacts at your disposal helps you to tap into them whenever you need to influence other stakeholders within the enterprise or make sure your project gets enough attention higher up in the company ranks.

Another group of colleagues, who can help you with user requirements, can be found in sales, account management, or customer support teams. The people working there have daily exposure to clients and can provide you a lot of feedback about user needs and frustrations. However, always keep in mind that context from which this feedback is coming. For example, the client support team might be dealing with the people who use your product while the salespeople and account managers could be dealing high top-level executives who make the purchase decisions but don’t actually use your software.

Build or Buy

An opportunity, which is not available to startups, is growth via mergers and acquisitions (M&A). 2018 has already seen a record amount of M&A deals globally. A big part of this trend is the mega-deals, like a recent AT&T acquisition of Time Warner for $85 billion. However, a part of the deals are small in terms of valuations and they generate better returns, according to a study by Harvard Business Review. There are a lot of small startups with single-point solutions out there, and project managers at enterprises should keep in mind that sometimes it could make sense to buy them out instead of trying to copy their solution. A project manager might not be the decision maker for such a scenario but can be the one to bring this option to the table.

Challenges for Project Managers in Enterprise

Approvals Take Longer

As a company grows, a hierarchy of reporting grows with it. Multiple departments, processes, and procedures come into place. Brand guidelines are created. Legal risks, sometimes overlooked in startups, have to be taken into account. A quote for a joint press release with a new partner could take a couple of weeks to gather all the sign-offs needed.

This means that a project manager needs to plan much more in advance and be more diligent. However, there are always ad hoc and unexpected situations where you need to get all approvals as fast as possible. Having good relationships with other departments in such situations will be of great value. A project manager who is able to help others in need will, in return, more likely receive favors from colleagues.

Miscommunication

“Assume nothing” should be a project manager’s motto. As complexity grows within a company, the project manager’s job becomes more difficult in terms of maintaining effective communication within and outside the project team. Let’s have a look at an example scenario.

Your team needs a couple of new icons for the new features they are working on. You unexpectedly meet the design team lead during lunch and tell her about the icons. She says they are actually working on similar icons right now and will have them ready soon. During the next day’s stand-up, you relay the information to the team and tell them to reach out to the design team when they will need the icons. The features in question are due in 4 weeks so everyone assumes the icons will be ready at that time. Developers put placeholders for the icons and only during QA someone notices that they forgot to replace them. They scramble to reach out to the design team, which has actually postponed the creation of those icons due to other urgent tasks. No one from your team has reached out to them and the design team lead assumed that you won’t be needing the icons anymore. The brand guidelines do not allow you to go to production with any random icons and your team is left sitting there with completed features unable to deploy them.

The job of a project manager in an enterprise is filled with such moments ripe for miscommunication. There are two strategies you can employ here:

• Use the retrospective to figure out with the team if a new process could help out to avoid such mistakes in the future. Perhaps keeping a list of all dependencies from other teams with weekly review and follow-ups could be the answer in this scenario.
• Over-communicate. It is generally a good strategy for a project manager to communicate more than you think you need to. Getting into the habit of checking in with people, asking for quick updates in those short moments while waiting for the lift or going to the car. It’s a good way to make fewer things slip through the cracks.

Move Slow and Don’t Break Anything

The older the codebase, the harder it becomes to develop new features. A project manager might start to notice that smaller startups are getting to market faster with new innovations and outcompeting them.

At the same time as fending off challenges from small startups, enterprises also have to be wary of similarly sized competitors. As startups mature, single-point solutions become full-fledged platforms, which have various different features and use cases. Feature parity with other big competitor enterprises becomes an issue.

As a project manager in an enterprise, you will have to make decisions, whether to engage in innovation and create new value propositions for your clients or try to attain feature parity with your competitors. However, most of the time you won’t be able to make such decisions yourself and you will have to work to influence multiple stakeholders to make these decisions for you. This can be frustrating, especially if those stakeholders are less digitally savvy, and they are unfamiliar with the features you are trying to convince them to build.

Conclusion

In this article, we discussed how the underlying mechanics of a startup and an enterprise create opportunities and challenges for a project manager. While in a startup, a project manager is likely to take on a lot of functions of a product manager, but the two roles are clearly separated in an enterprise. Keep in mind that each company is unique and not all of the topics discussed will apply to every situation, so nuanced environments will require a project manager to utilize different project management qualities and skills.

To recap, a startup has fluid processes and the project manager is able to make quick decisions and have a large impact on the overall company. The development lifecycles are much shorter, which allows the project manager to remain agile and be able to adapt to changing market conditions.

A project manager in a startup also faces considerable challenges. Not fully defined responsibilities can lead to many problems as a startup grows. Clients and co-founders might be pushing a project manager to commit to more than the team can reasonably deliver. Following that, various shortcuts can be put into the roadmap, which leads to legacy problems in the future. Co-founders of a startup are very active in defining the roadmap. Their convictions, however, can lead to false positives and the project manager needs to be data-driven and agile to mitigate these challenges.

On the enterprise side, a project manager can utilize the credibility and track record of the company to establish good working relationships with external parties. It is easier to gather requirements from seasoned executives and colleagues, who interface with clients on a regular basis. Lastly, a project management office, however constraining, can help to mitigate problems and manage risks that arise during project execution.

The challenges in enterprise project management are inevitably related to the size of the company. Various approvals and sign-offs mean that a project manager needs to plan very diligently and engage the PMO to avoid slowing down the project execution. Miscommunication is likely to occur as more and more people and departments are involved and this has to be mitigated by putting the right processes in place. Lastly, development lifecycles become longer, and a project manager has to compete both with startups and other enterprises in the market.

These are the core differences, between these two environments that project managers work in. By understanding these challenges we can better predict what we might encounter moving from one environment to the other.