Should I disclose technical constraints and details to the client?

Question

Background

In our Software Requirements Specifications (SRS) we have a clause which states that the user should be able to make push notifications from the website to the mobile devices.

Should we inform the client about the constraints of the feature? For example:

• Android limits push notifications to 1024 bytes
• iOS limits push notifications to 256 bytes

Should I inform the client that they will be limited to 128 characters in push messages, with translates to 1-2 sentences at best?

The General Question

Which is better:

• Constantly email and request meetings from the client informing them about literally all the details and constraints which technology enforces on all different features?
• Keep a "smart amount" of information which is withheld as "technological details?"

We are currently at the point where we are emailing the client at least once or twice a day, and sometimes even three of four.

Answer 1

The short answer is yes.

You absolutely want to keep the client informed of limitations or other gotchas in the project. You rarely will know the full story and thus lack the perspective to know if this will be a major impact.

A longer answer needs to dig into how you got where you are. Ben, Miles and CodeGnome all touch on this in their answers. I'd boil this down to two key points.

1- Spend more time designing with the customer: Even in agile, you need to spend some time understanding what will be done, with the customer. The requirement "should be able to make push notifications from the website to the mobile devices" is extremely vague. There is no use case here. What will the customer being pushing? How often? How mission critical is it? If you understand how the feature will be used, you can then design the feature better. If using Scrum, having the customer in your Sprint Planning meetings means they can answer questions real time.

At the very least, you need to document what the acceptance test is for this feature. What is the measurement of "done"?

2- Don't be afraid to over communicate. Instead, embrace it as part of the project. Set regular meetings with your customer (say maybe Sprint Demos) where you can go over the product. Not only can you share limitations, you get to show them how the project is going. It may turn out they really thought they wanted a blue GUI, but on seeing it they realize they really need a green one.

Make this kind of communication a regular part of your project. You will find you are much less surprised along the way.

Answer 2

Have a Communications Plan

You appear to be missing a Communications Plan, which is an essential aspect of most projects. This plan would include details such as what your stakeholders need to know and when they need to know it.

Be Agile: Don't Prescribe Implementation Details

From a more agile perspective, a better question is whether or not the implementation details prevent the team from reaching the objective. For example, if the Sprint Goal for an iteration is:

Enable push notifications from the website to mobile devices.

it is generally up to the Development Team how the goal should be implemented. There are many technical solutions to protocol and transport issues; the questions will generally boil down to:

1. What's the easiest thing that could possibly work?
2. What are the trade-offs in terms of time, money, or effort to implement any given solution?

When You Can't Meet the Objective

I don't think your example is such a case, but there are certainly times when a feature or goal can't be implemented on time, within budget, or with the skills or resources available to the project team. Those types of blockers should absolutely be addressed with the stakeholders in a framework-appropriate way. This allows the project's sponsors to make informed strategic choices, and is a key responsibility that belongs to the project manager or Product Owner.

Determining whether something is really a blocker, or whether it's simply a challenge that needs to be resolved, is the core differentiator in how to communicate effectively about an issue. How you make this determination will depend a lot on your project management framework, your communications plan, and (ultimately) the skill level and experience embodied by the project's leadership. Your mileage will therefore vary greatly.

Answer 3

Keeping the client informed is never a bad thing.

That said, how you communicate this should depend on the impact of the discovered constraint.

In the event that a constraint means that a specified requirement cannot be delivered, I'd communicate that early, preferably face to face, along with (where possible) some options on how to proceed to meet the requirement (maybe you need to agree more time, cost spent on different tech etc).

For things discovered that don't directly compromise a requirement, you could communicate these less urgently via pre-existing channels (e.g. as part of a regular status meeting or risk/issue report).

Another consideration might be how easy it is to change direction later. Be more active about communicating things that will be difficult to reverse at a later date.

Answer 4

Developing the means and levels of communication early in the project is an important PM detail. Some clients will want every detail, other will only want communication regarding specific issues. If this hasn't been established it may be a good idea to talk to the client regarding the frequency of communication and see if they are happy with the status quo or if they would like non-urgent issues bundled into a daily or weekly communication.

As a specific to this situation, you are creating the functionality as required and you can't adjust Android or iOS system contraints so this is non-urgent unless the wording of the clause implies functionality that you are not able to deliver.

Welcome to PM SE!