Stakeholder Communication and Project Requirements for PMs

A software project manager’s role is to provide their development team a clear path in developing a complex project that meets their product team’s or client’s expectations, on time, and within budget. That’s a daunting task as companies and jobs depend on you. There’s more to getting a project started on the right track than getting the tech stack right. Starting your project off right depends on talking with all stakeholders and gathering information that can impact project requirements. 

The Project Manager’s Responsibilities

In particular, we want to look at the project manager’s responsibilities as relates to the most frequent causes of failure. Good references for the causes of failure and PM influence on ROI include the Project Management Institute’s Pulse of the Profession: 2018 and 2020. PMI’s 2018 report cites seventeen reasons for project failure, of which two-thirds relate directly or indirectly to the project manager’s responsibilities. They can be streamlined as failures in:

• Knowing organizational priorities
• Understanding project vision and business objectives
• Assessing project opportunities and risks
• Defining project requirements and specifications of the technical stack
• Formulating cost assessments
• Forecasting and managing resources and dependencies
• Contingency planning
• Keeping projects on track

Almost all of these points can be narrowed down to a lack of communication and insufficient research in defining project requirements. The two overlap to a significant extent, but most points of failure originate in the effort (or lack of it) that takes place before development even starts. 

Project failure due specifically to developers or “the team” can still be a factor, though it constitutes a minority of reasons. One must figure that most teammates will do their best to deliver what’s asked of them. If the details for the tasks given to them are wrong, what they deliver will be wrong unless they catch it. 

Communication with ALL Stakeholders

Project managers need to communicate with all stakeholders. That can be a long list — your company executives and sales team, the client paying for the software, their customers and end-users, your development team, and vendors, especially IT staffing agencies. Each may have information, news, or upcoming plans that can substantially impact your project. Midstream changes equate to added expenses, rework, and delays that can compromise success. Let’s cover a few reasons for each stakeholder that may not be self-evident in the project itself. 

• • Executives know the health of your company (impending layoffs, hiring freezes, recruiting plans). We’ll add the sales team in here, too. They’ll know about major marketing initiatives and where other prospective clients are relative to signing development contracts. More impending projects can impact your available resources like requiring developers to multi-task. In turn, this may require talking with your IT staffing agency for timelines to hire developers with specific skillsets. Include the founder, CEO/CTO, and your chief of sales for possible changes in priorities and resources.

• • Clients, the party hiring you for software development, deserve a lot of attention. Non-tech companies and those new to software development may not know all of their options. Software is evolving faster than most people can follow. They may not know the data they can collect could be worth more than their products or services. Maybe they’re missing a vital component in their software idea for it to be competitive. If they become aware of that later, they may ask for changes and additions. See where they are at, but be prepared to educate them about their feature and data options. All this also fair if you’re working in a product company with non-tech leaders.Also, keep your radar on for tech changes and useful new technologies. This includes things like Google and Apple dropping support for 32-bit apps, Apple’s dropping of Intel chips, or security concerns over Huawei 5G chips, and the like. The software you develop may require changes simply because of changes made by other companies or the discovery of new security vulnerabilities.

• • End-users are being drawn in earlier in conjunction with Participatory Design and Development, and with MVPs in general. In the past, a lot of design and feature elements were driven by the client. Today, we can statistically validate what end-users like and why. End-user discussions will likely take place during development. But, take a look at any marketing research they have, target-market data, and *competing products* before starting on project requirements. The most important part of an MVP is collecting maximum useful end-user information and feedback. 

• • Team-member communication is obviously critical and covers a lot of ground in daily tasks, code reviews, retrospectives, and more. You can support their long-term performance by maintaining and enforcing coding standards. This extends to your definition of “good enough code” and promoting the resources and tools you want them to use (vs. creating new solutions from scratch). But, there are a few more items to cover.Clearly defining tasks in the project management software (PMS) you use can avoid a lot of ambiguity. Make sure everyone knows how to use your PMS and knows the standard for clearly describing their work. The proliferation of PMS options like Jira, Monday, ClickUp, Wrike, Basecamp, etc.(Check: Monday vs. ClickUp) is an indication of some discontent — and fatigue. Turnover among software developers requires keeping a keen eye up in the crow’s nest. Take a deep look at Why Software Developers Leave so you can spot the triggers and performance indicators that a developer’s about to burn out or look for another job. Few things are more disruptive or costly than losing a developer midstream on a project. 

• IT Staffing Agencies like YouTeam play a vital role when you need to rapidly ramp up your team or replace developers who have left. Your staffing agency can provide you with going rates for each position you need and timelines for hiring. This is information that reinforces your ability to provide accurate cost estimates. Project managers are responsible for and should incorporate contingency planning in their project requirements. Offshore staff augmentation provides you faster access to a larger talent pool and substantial savings compared to the fully-loaded cost of hiring in-house developers. 

Project Requirements

All of these communication elements underscore that there’s a lot more to project requirements than merely defining its technical stack. Upfront, that seems to imply an awful lot of work. In a sense it is. After some time, it will seem normal and natural. One should also observe development encountering fewer problems, too. There’s a lot of information to be gathered that’s essential to even start on defining project requirements, say nothing of a proper cost estimation. The software’s usually contracted based on the software estimation fitting the company’s budget, and that’s one of the components of a successful project. 

The following is an overview of the process that one top-ranked development agency from Silicon Valley uses for defining project requirements and delivering a professional software development cost estimation:

1. Understand your customer needs – the software’s function, audience, and objectives.
2. Define the software’s modules, components, technologies, and other requirements.
3. A roadmap that defines the sequence in which the components will be developed.
4. Create a storyboard or wireframe to show how all the parts will fit together.
5. Verify the customer agrees with items 2-4. If not, make changes and repeat.
6. Determine the project’s tech stack – languages, technologies, third-party resources, etc. Compare these technologies to what you can and cannot cover with your existing team (in-house & outsourced).
7. Identify and assess issues that may impact development like R&D for a new application, regulatory approval, parallel development with devices, etc.
8. Verify the customer agrees with items 6-7. If not, make changes and repeat.
9. Determine the delivery date or deadline.
10. Effort estimation, plug everything into Gantt Charts to finalize the software cost estimation. 
11. Does the customer agree? If not, use Cost-Effort-Scope to revise as needed.

Needless to say, a roadmap, storyboard, fully-defined tech stack, effort, and cost estimation is a lot of work. But, this process delivers the kind of estimate that a company can take to an investor and stand up to experienced scrutiny. It also minimizes the chances of getting off on the wrong track and costly rework that means later. That agency charges a fee for these deliverables, but they absorb the cost if the customer contracts with them. 

Of course, your company priorities may mandate being able to provide a much faster cost “free” estimation. With experience, you can probably get a pretty good feel for “ballpark estimates.” Either way, keep track of your work for future reference. After you’ve delivered the software, come back and look at your effort and cost estimations to see how close they were. Try to define the reason for any significant deviations. 

The Tip of the Iceberg

Project management is complex. It’s not just about defining what needs to be done, but being aware of and guarding against a wide variety of obstacles and hazards. It’s said that the best way to get to where you want to go is by helping others get to where they want to go. Your ability to deliver software projects according to client expectations, deadlines, and budgets is critical to their success. If you can do that, they’ll continue to contract with you, possibly add new projects, and recommend you to others. Hopefully, we shared some thoughts with you that you can use to help your next project run smoother with fewer disruptions.