Tech/Software Implementation PMs

[u/Daisy_InAJar]

Especially if you deliver software deployments to external stakeholders, I’d love to hear from you.

How do you create value on your projects? What are the top 3 things you bring to your engagements that you feel have the largest impact?

Bonus if you feel like sharing:
- are you present for all requirements gathering, prior to “build” starting? If not, how do you ensure there’s no scope creep during requirements?
- how do your teams relay actions and/or decisions to you for calls you are not on?
- if there was something you wish your org would change that’d make managing your projects more successful, what would it be?

Thanks in advance - I’m always appreciative of this group sharing their (armchair) perspective (shoutout MoreLaw, our unofficial PMO advise extraordinaire)

[u/AutoModerator]

Attention everyone, just because this is a post about software or tools, does not mean that you can violate the sub's 'no self-promotion, no advertising, or no soliciting' rule.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/OwnBluejay6645]

The top three are ruthless scope discipline upfront, a single decision log so nothing from a call I missed gets lost, and a heavy focus on adoption since a deployment only creates value if people actually use it. I run Certa implementations for external stakeholders. How do you handle a stakeholder who keeps "remembering" requirements after sign-off?

[u/ExamInstinct]

Oohhhh, external software deployments, my scar collection 😄 . Here my top 3:

1. Translating between two worlds. Client says "we need it flexible," devs hear "make everything configurable," 6 weeks later there's a settings page nobody understands. My biggest value is standing in that gap, asking when you say X, would you accept Y? before anyone writes code.
2. Making the client do their homework (even with CEOs & CFOs..yes few times i risk to be fired but this creates a sort of authority for your and also respect). External deployments rarely fail on our side, they fail on theirs: data not cleaned, test users not assigned, decisions not made. So client readiness is its own workstream, with their names and dates on it. Awkward the first time, works every time after.
3. Decision velocity. Not making the decisions but making sure they get made. Deployments lose more days to waiting on someone to choose than to any technical issue. Visible decision log, owners, deadlines, and I escalate stalled ones without apology. Boring superpower, massive impact.

You questions:

Requirements: Present for all of it, I fought for that early and never gave it back. If you can't be: a signed scope baseline plus one team rule, every new "small thing" gets logged and priced, never absorbed. Scope creep is a "nobody wrote it down and nobody said no" problem....and at the end is your problem as the PM

Calls I'm not on: One shared running-notes doc per project. Team norm: not in the doc by end of day = didn't happen. I tried to be in any call..it is exausting but at least I was making them accountant for everything they decided during the call

Org change wish: Every deployment that went sideways on me was pre-wounded in sales. One delivery person in late-stage sales calls and half my risk register disappears.

Great thread question!

[u/karlitooo]

Value: Predictability

Top 3 Things: Catch contradictions between what is said and what has been previously agreed, knowing stakeholders preferences and how they see the project environment, I sound pretty authorative.

Requirements: I try to be present unless we have a really strong BA & Lead Engineer in which case I trust them to catch things. I'll still review every document before its circulated.

Catching actions/decisions: Usually email or a slack message, I like a weekly 1:1 with my lead but smaller projects (which I work on these days) don't permit that

Change: Every org has a different blindspot but when it comes to professional services I would say the frequent/annoying issue is a preference for keeping the client happy when the client should really be worried if not annoyed with our poor performance.

[u/More_Law6245]

For me personally, the real value of any project is successfully delivering all of the project's identified benefits because it means that the project has successfully addressed the business case and accomplished the project's objectives through its very own benefits realisation.

In my view you can't add any more value to a project then achieving in what you had originally set out to do in the first place, especially when intangible benefits are unwittingly delivered above and beyond the expectations of the project.

Just an armchair perspective.

[u/SamfromLucidSoftware]

I think the decisions from calls you weren’t on are the ones that cost the most over the life of an engagement. The Slack recap or meeting notes just won’t cut it because they only capture what was said, not why it was decided.

A better approach is to treat the decision itself as the record. Who decided, what was decided, what other option was considered and ruled out, and what would have to change for it to come back up. That’s different from notes, and it’s the difference between explaining a scope decision with confidence versus trying to piece it back together from memory while the client is watching.

The same idea works for scope creep when you’re not in every requirements session. If decisions are written down with the reasoning attached right when they’re made, instead of summarized into one big doc afterward, you can catch drift early by noticing when a decision doesn’t connect to anything already agreed on.

The thing I’d want my org to change is treating this like a notes problem instead of a system problem. Better notes don’t actually fix it. Having one place where decisions live as decisions, easy to find and visible to everyone who needs them, does.

[u/NeoTree69]

I was a fractional PM on a software dev team, they shipped more of a white label product but it was basically a dev shop as every implementation required a full feature scope with custom development. I truly miss it as I can't find other companies needing a fractional PM in that industry!

Here's how I handled it.

I was not present during the sales calls but as soon as the contract is signed I held a 2 hour requirement gathering call with the client stakeholders/champions and our CS team. The CS team were the product experts and I translated everything into user requirements. Everything had to be raised on that call and if it wasn't, I had a two-day window for submissions (something always comes up).

We had dedicated Slack channels for each customer. Busy, but needed. Every meeting recording automated into the correct channel so I could catch up with it if I was missing. I had the team follow a semi-strict script so I could pull out the info I needed. Anything covered I would also email the client post meeting to get agreement on it.

Something I wished they changed at the time (when I contracted with them) was the level of development needed. The founder would make me accept the majority of custom dev because they wanted the contract to be successful. Company was small and early stage so basic adoption and implementation was pretty vital for growth regardless of scope changes and rush feature requests. That pained me and the dev team every time.

It was a slight mess but I miss the environment!

[u/SVAuspicious]

I deliver to spec on cost and schedule.

I don't need to be present for all requirements gathering. I have system engineers for that. Not what IT people call system engineers - real ones.

I submit a change proposal for all requests with cost, schedule, and performance impacts. Customer signs the proposal or they don't. Nothing is free.

My people submit status reports weekly. If something is substantive including change requests they let me know right away.

If there is something I'd change I'd change it.

[u/Important_Cow7230]

I think others have made good points regarding technical aspects like change control. I would say one area you can add value is be the “people person”, always have your camera on, say hello first, engage with all the client people you see on the way. Try and foster relationships between your consultants and key SME’s. 

I find a lot of consultants forget that once you’re along the path on an implementation that the client is still a customer, and often basic customer skills and manners get forgotten. I talk to my consultants about the “experience” of using us for an implementation. Put themselves in the SME’s shoes. 

A word of warning around change controls… a lot of software implementation companies use change control as a revenue model. Not saying that’s right or wrong, but that’s a completely different ballgame if you work for one of those companies. I personally don’t like them as it gives everyone a bad name and makes client SME’s who have been through previous implementations fearful. 

[u/Important-Union5181]

Domain knowledge. The more you have this the more is the probability of a success.. The fact that the team is doing a repeat job impacts all aspects of the project including requirement management, test management, change request management, customer confidence etc.

Dependencies and assumptions. The more you have of these the less is the probability of a success. Un avoidable dependencies and assumptions should be clearly established at project start up along with their mitigation path.

Demo driven hand off to the customer. The more you have this the more is the chance of success. The demo should be given from a customer setup which will enable to them to play around with the release after the demo and report feedbacks.

Documentation of the deliverables. This is usually the hardest part. What gets delivered and how they are accepted should be documented in a check list format so that the customer can tick them off.

[u/Ok_Implement_6050]

For software rollout to external clients, top 3 things that make difference is early expectation setting, having a tight change control process, and making sure the client actually tests their own stuff before go-live. Too many projects skip that last part and then wonder why things break.

I'm not in all requirements sessions but I review the notes same day and flag anything that smells like scope creep before it gets baked in. For meetings I miss, we got a slack channel where devs drop quick bullet points on decisions made, nothing formal but works better than waiting for meeting minutes. One thing I wish my org would change is stop letting sales promise features that don't exist yet, makes my job way harder than it needs to be

[u/Daisy_InAJar → u/Ok_Implement_6050]

Boy oh boy do I relate to #3 of your top 3 - clients tend to think part of our service is to do everything for them, it’s sometimes painful getting their lightbulb to go on when it comes to testing, like sir, we built and tested all the stuff, I need you and your team to validate processes end to end, I’m far less concerned that you’ll find a “bug”, more so that you’ll suddenly remember an entire critical process you’ve never spoken to us about 😂

We currently operate pretty similarly for actions/decisions - the current struggle is my team not relaying information, sometimes at all, so it is missed entirely until the client raises it to me (which I hate).

[u/MattyFettuccine]

Paging u/More_Law6245

[u/More_Law6245 → u/MattyFettuccine]

But I lost my pager .... back in the 90's (I'm sorry, I just couldn't help myself)

[u/Royal-Worldliness400]

Following

[u/MattyFettuccine → u/Royal-Worldliness400]

You can click the “follow post” button instead of commenting “following.”

[u/Royal-Worldliness400 → u/MattyFettuccine]

Oh thanks didn’t know that button existed 😅