I’ve been seeing some patterns lately. There are precise points in a digital consultancy or agency workflow that can either lead to healthier projects and higher profitability or to a Shining-like bloodbath filled with reactive estimating, scoping, and selling processes that gut a company’s cash flow within months. Doing it right involves collaborative scoping, flexible contracts, and a team that is dedicated to continuous improvement.

To investigate an example of what healthier workflows look like in real life, I sat down with Michael Luchen—the Senior Digital Project (recently turned Product) Manager at Crema and great guy who has spent his whole career working on continuous improvement in a welcoming agency atmosphere that fosters learning, collaboration, and early project Management involvement. We talked about how PMs can create value and alignment right from the agency sales process and throughout operations. We also talk about how he and his team make room for continuous improvement, and how that commitment to being better actually shapes a more robust framework for longer-term collaborations with clients, more revenue, and higher profit margins.

The PM intersection between technology and communication

Michael, how are ya and how the heck did you get into this role?

Hi! Well, I was always a nerd. I was interested in technology, and loved building computers and doing all sorts of hacking and stuff like that with my friends. But as I grew up and I started looking at degrees, I didn’t find what I was looking for. Math and stuff like that isn’t my strong suit so that left out programming and development. So anyway, I ended up going to the KU School Of Business and I was looking at general management degrees, but I came across information systems and kind of really fell in love with that because it sat at the intersection of being a nerd and being a businessperson—right between technology and communication—with information systems sitting right in the middle.

That path sounds fantastic and similar for other PMs I know.

Agile estimation and scoping

Okay, let’s get into it. There are a lot of unknowns in Agile projects. The bigger the project, the more grey there is in the estimating process. What do you think are some really important things you do to get to that initial ballpark correct so you can fill in the gaps?

Get the development team—the people who are actually gonna be doing the work— involved early if possible in order to get an accurate ballpark. You need time to break down whatever the requirements are. Writing user stories and some light technical research, at a minimum, before estimating helps provide a reasonably accurate estimate. I think there are also times where you can bend that rule a little bit if it’s something that your team has done before. So it’s kind of up to the project manager to make that call. As you work through the scope, the estimations will become more accurate. The more experienced your team is, the more straightforward it will be. And if you have a discussion with your team, you can also get a lot farther with those estimations than you could with a vanilla team that has never worked together.

Talk about your process during sales: how does this estimating and scoping happen?

Prior to an engagement starting, we’ve done two things during the sales process when we’re trying to sell work to a new client. First, we’ll work with our technical director to figure out what a good ballpark to work with would be and our technical director, if there’s any uncertainty, might do some research himself. And then we’ll also talk to the development team individually to refine that ballpark at a very casual, very high-level perspective, which works well with the type of contract that we set up.

There are other times where we need to provide a more accurate ballpark estimate. That’s when the project manager comes in and works with the strategists to ensure that user stories are written in, broken down, that the team understands what those are and can ask questions about them. Our project managers act as facilitators during the story estimation session, highlighting any concerns about what the estimate means and things like that.

So here’s a question for you. Does that process of breaking things down into user stories occur before or after that contract closes?

Typically it occurs after, and the reason why is that we found success in a having larger multi-month contracts with our clients that basically provide them with a product team for hire. It’s not specifically tied to any deliverables. In the past we tried doing discovery on smaller scopes and figuring out what the work is, breaking it down, and estimating it. But the problem with that is from an agency model perspective, you end up introducing more gaps between multiple contracts, which means more idle time and fewer profits because you can’t bill a continuous contract.

You’re taking a bit more of an Agile contract approach where you’re looking at the relationship (aka reserving the team) as the thing you’re billing for, not the deliverables, so to speak. How do you approach a contract like that? I know a lot of our PMs get stuck writing those contracts and want to know ‘how do I write an SOW that doesn’t contain anything specific around scope?’

Yes, this contract is fundamentally different. You’re not promising features, you’re promising your team. We write our contracts around getting two full-time developers for x amount of weeks or months, for example. You’re getting a half-time test engineer, you’re getting a quarter-time designer, you’re getting a quarter-time strategist and a half-time manager. We do throw in other language around what you can expect to get as a client for this team rate because understandably that’s a little uncomfortable for them. It’s something we deal with every day and it’s challenging. We explain it and why this approach is beneficial. But we might say, you can expect to have a weekly or bi-weekly call to review your product backlog with your strategist and your manager. You might expect to see reports from your test engineer, and you might expect to participate in our sprint planning meetings and things like that.

You can really pull it back to looking at the long term relationship instead of just, ‘hey, what are we squeezing (in terms of deliverables) out of this contract’?

Yeah, absolutely.

Continuous improvement improvements

You’ve adapted your contracts and your approach over the years and it sounds like continuous improvement is really important to Crema. What things do you do to focus on as a team?

Leaving a legacy of shifting “project management” from Gantt and burndown charts to coaching, collaboration, and leveraging AI-driven tools would be something I could die and be happy with.

One of our core values is Constant Improvement. Just like the name implies, it means we are always learning as a company and as individuals. Day-to-day, this means we are consistently researching new technologies and processes to review and suggesting ways to deliver significant value to our clients. Our company also reserves every other Friday for “Innovation Lab Friday,” where we shift our focus away from client work to intentionally learn new skills or even build our own products. Over time, we’ve learned that these Lab days provide valuable learnings that we are able to apply to our client work.

Is there anything about your current processes that you’re excited about tweaking or evolving? Is there anything on the back burner that you’re thinking about?

One of the things that we started doing for each discipline at Crema is a process improvement project. We use Kanban boards for documenting new ideas and feedback from each team. Then each reviews and prioritizes their lists about every other week and plans the processes for experimenting with them. After the experimentation happens, we move it into a review area where we’ll monitor and ask, is this really working for the team? How can we try this again? Things like that.

What’s at the top of your list?

So I’m literally looking at it right now—the one at the top of our idea column is about improving the presence of scrum goals. So we wanted to figure out how can we improve the sprint goals and scrum from a visual perspective on a recurring basis. We’re experimenting with things like how to work better in vertical slices, and how we better define ‘done.’

Weird question: what would you do if you’re the only PM and you had to spearhead all of these process improvements? This is a thing we commonly hear about where there’s just one PM in an organization whose struggling alone to make change.

To me, it’s about a method of asking for forgiveness later and experimenting along the way. So early on, this attitude was how we got to work on things like our Agile contract. We just throw everything out and figure out what works and try and experiment with things.

Because PMs are so integrated into the flow of our company and product teams, they naturally have a really great feel for the pulse of how things are operating. PMs know when something’s is off and not operating the way it should be. They can understand the pain points, so PMs can ensure processes are created, iterated on, and replaced if they get old. The ‘engine’ is the unique set of processes a product team or company has. The PM monitors the engine to make sure it’s always operating well and is able to tweak or ‘oil’ it when they need to.

So, it comes right back to working through these processes directly with upper management and feeling open to evolving if you need to…

Yeah. And sometimes just really taking that initiative yourself. Just do it. The worst thing that can happen is that you do the work and somebody else tells you ‘no, let’s just keep the status quo.’ If that happens, then you try something different the next time.

For example, every week we have a recurring project management operations meeting and one of the standing topics of that meeting is to try to split up the work to do and to select some processes that have been prioritized to improve on.

Just do it. The worst thing that can happen is that you do the work and somebody else tells you ‘no, let’s just keep the status quo.’ If that happens, then you try something different the next time.

Managing up and sideways

I remember you saying something about PMs being the oil in the engine in an article you wrote a little while back. What does that mean to you?

I believe really effective project management is subtle or invisible to the team. In an Agile environment, project managers should dedicate their time to making sure that processes, tools, and culture are established around and built for and by the team. This culmination of team, processes, and culture represents the ‘engine.’ Throughout the lifecycle of a team, it’s up to the project manager to monitor and tend to the efficiency of this engine. Metaphorically speaking, if a process ‘gear’ is not functioning well with the rest of the engine’s operations, it’s up to the project manager to identify that and ‘oil’ it (fix it), before the full engine slows down or comes to a halt.

Let’s talk about how this translates to operations, sales, and managing up. What’s a PM’s responsibility in terms of business development support, if any?

As soon as sales starts talking time and allocating team members starts, the PM needs to be involved. They need to help guide the discussions around making sure a project has the right resources and that people are talking about all the potential risks. They should also make sure the team that is doing the work is able to work with the business developers. PMs can play a good devil’s advocate role in business development to help thoroughly vet new engagements.

And how does a PM help with operations?

Because PMs are integrated into the day-to-day work of product teams, they are able to speak up about company processes and operations to help keep projects aligned. For example, PMs might help improve our design prototyping process which is a company-wide operations improvement.

So I want to talk a little bit about the relationship that project managers might have with management layers, executive leadership, even owners. Because we’re specialists in preventing scope creep, identifying risk, and pushing back on stuff that isn’t in the contract, or isn’t part of the ongoing estimating process, we run into a common situation where we have to say no and owners or management layers may want to say yes to get the sale. How do you navigate a scenario like that, especially when we’re talking about Agile delivery?

Investing the time to game out scenarios is a great way to illustrate these risks. If you can show the “why” behind pushback, then it becomes more of an objective discussion and less of a subjective one. It also opens up opportunities to find the right solution for the sale. For example, the team may be debating a high-value engagement that requires some stipulations in the contract that would need to be proven over time. There’s a chance these stipulations could generate a significant risk for the team and client if they turn out the wrong way. In a situation like this, I’d recommend smaller is better—offering the client a smaller contract to identify the answers to these challenges could be much more beneficial for a valuable and long-term relationship.

I also believe there’s an opportunity to prevent these types of discussions in the first place within the context of Agile delivery. Like I mentioned, we’ve worked over the years to structure our Agile contracts in a way that puts a focus on the value of our product teams—not the product itself. This shift in contract focus, away from ‘what do I get’ also naturally supports recognizing the benefits of Agile delivery. It can be a more challenging sales process, but we’ve been successful with this model.

What makes this process easier, do you think?

I think a lot of it comes down to investing in the time to build trust with our clients and have the opportunity to walk through our processes. With our duration and price contract approach, our clients are essentially in the ‘driver’s seat,’ surrounded by a team of expert navigators. Once our clients see that, we see a ton of success. However, it takes time to get there. Sometimes, we need to be prepared to start with small engagements so that our clients can experience our team and we can earn trust for valuable, long-term relationships.

A recent Chaos Standish report said about seventy percent of all projects are either extremely compromised or fail. And usually, the reason is because of a lack of project management or a lack of collaboration and alignment. So if we know that most projects are failing, what would be your gut instinct as a PM in terms of how you need to stand behind project management as a discipline?

It’s so hard to summarize the value of project management. It’s so hard because it’s—it’s like everything. Leaving out project management is like having a car without the engine. You won’t see the engine, but without it, the car won’t run. Project management isn’t just one thing, because it helps keep everything on track and helps keep everything organized. It makes sure things don’t fall through the cracks. And if you’re a developer or designer, that’s not what you do, and that’s not what you want to do.

So what do you push for as a project manager?

If there’s a concrete project management role or responsibility area of focus that people should push for, it would definitely be having project management involved in sales because that’s really where project management starts and it’s very easy for a lot of companies to think project management starts when the project starts. It actually starts when any discussion around the project starts.

As soon as that thing closes, you’re already starting to converse about like what it will look like to the team.

Yeah. You’re setting expectations in those very early conversations as well. I mean, even if the contract is perfect, we all know that contracts once they’re signed and filed away, no matter how many times you read them or review them before they get signed, it doesn’t matter. The contracts don’t matter. At the end of the day, what matters is the relationship and understanding that you’ve built with the client.

Leaving out project management is like having a car without the engine. You won’t see the engine, but without it, the car won’t run.

Alright, Michael. We’re going to wrap this up with a little futuristic reflection. Close your eyes and imagine you’re 85 years old. Two questions: How is project management different and what legacy are you thinking about leaving as you lay on your deathbed?

Based on my teams’ experience in defining what great PM is, I’ve started to develop a rough and personal theory on what the future of project management will be like. It’ll be focused on how we work together as humans. If PMs put their energy and focus into effective collaboration techniques, psychological safety, and more—I believe their teams will produce significant results, be more engaged in their work, and have less turnover. I’ve seen it happening at Crema.

The challenge is this stuff is so vague—you can’t account for it in a spreadsheet and it’s difficult to capture in a performance review. And because it embraces vagueness in an industry focused on tracking stuff, I think this is and will be a monumental challenge. The organizations who choose to invest in solving this challenge will be the ones who lead with great PM in the future.

Thanks for digging into the world of PM with me today, Mister Luchen. Excited to check in with you and see how your continuous improvements are evolving. Can’t wait to connect again.

This interview was edited for length and clarity.

Michael’s tips for setting up a healthy PM environment

Step 1: Observe existing culture, roles, and interactions

Ask yourself:

• Is each role able to flourish within its own area of responsibility?
• Are there any tension points within how the organization is trying to serve its customers?
• Does the contract format or structure support what the organization wants to provide to its customers and be recognized for?

Step 2: Identify gaps and improvements that tie together all facets of the organization

For Crema, it was migrating standard projects from fixed scope (Waterfall) to Agile (Scrum, Kanban).

• It supported our mission of “Turning good ideas into great product experiences”
• It enabled our strategists and team members to suggest the best direction for our clients’ products on a frequent basis (i.e., suggesting a pivot to a client didn’t mean we had to write a contractual addendum)
• It enhanced our culture and client/contractor experience by shifting the focus away from contracts and “getting what was signed for” to creating and building the best products—and serving our clients in the best way possible

Step 3: Invest in learning and training

If you need education to support improvements, then invest in self-learning and training.

Dedicate significant time to scouring the web for resources

For me, it was teaching myself Agile methodologies like Scrum. Initially, my skills were self-taught and provided value to Crema and our clients. I later became a CSM and earned my CSP. The certifications are icing and support biz dev for chasing down bigger clients that value them.

Collaborate with your team to feather in learning into your contracts, active projects, and processes

• Start iterating on your contacts immediately
• Start iterating on your process immediately
• Start talking to and collaborating with your team immediately to get their input

Over time, these will improve to the point of relative stabilization, but testing with your clients and team is the fastest way to get feedback and achieve success. The worst thing that could happen is that you temporarily fall back into the old way of doing things.

Bring your team into your learning. Include owners and senior roles

• Have discussions about what the company should experiment with and why
• Have discussions about what experiments have worked and why they should be supported more in the future

When pursuing new clients, lead the experimentation process around new contracts. Take a completed experiment (e.g., a new Agile duration & price contract) and build it for a new client. Pitch it to the team and leadership for using with this client.

• Collaborate with biz dev roles
• Be supportive, not adversarial (something that tends to be stereotypical in our industry)
• How can a PM support biz dev goals? Typically, this ties back to how contracts are formed and what the process and involvement is
• PMs lead the look and feel of contracts that supported biz dev goals and needs
• After you reach an inflection point of experimentation and learning (you’ll know it when it happens), start standardizing
• Update your contract templates (use examples from your experimental ones—the successes and failures)
• Update and standardize relevant parts of your project management processes
• Collaborate with your team to keep all other aspects in sync: invoicing, resourcing, dev and design processes, etc.

Keep learning and experimenting

• One of Crema’s values is “Continuous Improvement.” We never stop experimenting and learning—particularly around process (from sales through product dev)
• Even as recently as this past week, we continue to actively refine our contracts and process to support this direction

Some tactics to systemize your processes include:

• Setting up a quarterly “Process Improvement Board” with a cross-section of leadership and talent across the company to provide feedback into processes changed in the last quarter and pain points that could be addressed in the next
• Having role-based teams meet on a regular basis to discuss process improvement
• Having recurring sales and operations meetings

Crema of the crop

Tips from the rest of the Crema team.

What do business developers often misunderstand about the PM role?

“I’d like to imagine a world where biz dev and PM work hand in hand every step of the way, but I know this isn’t always possible. People are booked on projects. There are organizational processes. Calendars conflict. The list goes on. That said, these two roles should lean on each other for their expertise and come together as a united front during any and all biz dev conversations. Biz Dev should frame up the ‘why,’ and PM should come in with the ‘how.’ Prospects appreciate this tag-team approach, and it demonstrates a true expertise when each member of the team contributes their full knowledge.” —Alexa

What is a project manager’s responsibility when they know a project is under-scoped or has serious risks?

Confirm risks with the project team

“Before raising any red flags, you want to ensure you’re not missing something. Often times, PMs do this naturally anyway and by the time they know a project is under-scoped or has serious risks, they’ve already worked with the team to identify the ‘why’ behind it.” —Tucker

Develop a plan

“Now that you know you have some legitimate problems, work to develop a plan of action to either mitigate the risk entirely or, at a minimum, figure out how you can at least take three steps in the right direction.” —Tucker

“I always like to start with finding the “why.” If the project is under-scoped, why? What technical expertise can help explain the added complexity? What real-world examples can we pull from to provide context? What would the timeline and budget look like if we expanded scope? What truly matters to the business and aligns with the goals?” —Alison

Raise your concerns

“Talk to your manager. This ensures they are in the loop before your client. The last thing you want is your manager finding out about any problems from your client. Additionally, share your plan of action with them to get feedback on the plan and how you should deliver your plan of action.” —Tucker

Deliver the news

“Whatever you do, do not deliver this news via email, Slack or any other passive communication methods that exist. If you can’t get in front of the client, or it’s not usual for you to do video calls, at least get them on the phone.

Reiterate that you’re all in this together and consider you and your team an extension of theirs. If your client wins, you win.” —Tucker

“At the end of the day, the PM’s role is to ensure that stakeholders have all the information they need to make an informed and responsible decision for their product.” —Alison

What should owners appreciate about their PMs and their relationship to revenue and the health of their company?

“The service you provide your clients will only be as good as the team that is serving them. In our industry, our clients are served by product teams made up of designers, programmers, strategists, testing specialists, and project managers. These individuals, all specialized, have to move and perform as one cohesive unit…and that is where our PMs come in. This role is vital in supporting and leading our teams in a way where they can perform at the highest levels of effectiveness and quality. This connects to our level of service, which is connected to our ability to serve more clients, create a healthy company culture, and in general maintain a strong bottom line.” —Daniel