How strictly can we differentiate the importance of Project Scope and a Product Scope for developers

Question

Is it always important for developers to know about the entire product before they get their hands on to develop a certain module of it? Let's say that if the customer wants to keep the product confidential then how can we go about letting the development team know what they are suppose to come up with? I'm seeking for effective approaches and ways to handle such scenarios.

Answer 1

If we're talking about a complex and long project, it's common to have developers working on pieces of the project. They will need to understand thoroughly... what impacts on their job. JonnyBoats gives the perfect example for this case.

On the other hand, there's a possible that the project be relatively small, with a few people working on it. I'd say that's the case, otherwise you wouldn't be asking. So... as several questions around PMSE, the most accurate answer would be... 'it depends'.

It depends on:

• Project Size: If it's a small piece of work (a confidential Hello World, let's say), it's almost impossible to keep things covered for developers. The piece of work he needs to do explains the project itself. Just re-added here what was explained above for cleanliness (and for the few people who jumped straight into the bullet list).

• Project Structure: Ok, let's say it's a fancy-revolutionary Hello World. There are four developers allocated plus two testers and a project manager. I'd say, as long it's possible to break down the work, only the project manager will have the complete view of what's being built. It will be pretty much one developer to define a string, another to type the code to print that string, two testers testing and the manager keeping sure everything is fine. Ah, the other two developers were fired / moved into another ultra-secret project.

• Project documentation: 'This project is intended to build up a nuke'. Well, regardless all your efforts to keep things hidden, you'll need documentation to help you out. If the project documentation given to the PM is clear enough to break down into pieces (and specially the interfaces between them) it's fine.

Having this in mind, that's what I'd do:

• Have the project clear in you mind: It sounds obvious, but remember that only the PM (i.e. you) will be the only person to understand the goal, you'll need to understand that no one else will be sure about what's doing, unless you confirm it.

• Split things up: Obvious again; my tip here would be to think of interfaces between pieces rather than any other 'splitting' method. Specially when explaining to the developers what they need to do... I believe that if you tell them what they receive and what they should provide is better than saying "you're doing the interface to receive secret data".

• Use mock+fake data: Eventually you'll need to populate tables for testing; use codes, numbers, words... anything but a data related to the table itself.

• Take a deep breath: As Kyle stated, developers are curious; making something classified will only excite them even more to figure out what they're doing. Because of it, the last tip would be:

• Trust in your team: Ok, you won't tell them what they're building, you're 100% sure that things are harder to manage / build / test / sign when working like this and there's still the possibility of information leakage. So, have a team you'd be confident to work with even if they had the whole vision of the project. There's always a possibility that, further down the road, they do.

Well Maxood, I hope you have success on your journey and hope you have the opportunity to share some thoughts and experiences with us in the near future.

Success!

Answer 2

Are there any benefits to keeping the developers in the dark other than the assumption that some amount of knowledge will be kept secret? Keep in mind that if your developers are smart enough and have enough clues, they might just figure out what the whole picture looks like anyways. And the air of secrecy might make them more interested in putting the clues together. My suggestion would be that if there is no NDA in place, that there should be one. And if you don't trust the developers with an NDA, then you should consider other developers.

If the developers do know the shape of the overall project, they:

1. will be more likely to give more accurate estimates for larger pieces of the project
2. will make smarter implementation decisions, leading to less rework
3. will be better able to ask the right questions
4. can point out when a detailed item they've been requested to do goes against the overall goals
5. can point out when two (or more) pieces of the larger project can be handled using common code

Answer 3

It is virtually never important in very large projects that individual teams understand the entire project. It may be nice, and it may make people happy to think they understand the entire project but that is another matter.

Consider the development of the atom bomb or virtually any other top secret military project. Clearly such projects get done and produce successful results; it is also clear that as few people as possible even know the goal, much less the scope and details up front.

The way this is done is to segment the work with each team dealing with a particular segment on a strictly need to know basis. Taking again the case of the original atom bomb in WW II, clearly they needed an airplane to fly the bomb, but when they requested an airplane the company that built it did not need to know what the payload would be, only it's size and weight in general terms.

Even when there is nothing secret about a project, it is still often parceled up with the various teams only having a general understanding of the entire project and not really understanding the other pieces. Consider when they design and build a new ship. There will be an engineer designing the propeller. That engineer will probably know that there is an engineer working on the electrical systems, but the propeller engineer probably doesn't understand what the electrical engineer is doing (unless he is curious about that).

Answer 4

My suggestion would be to find & appoint a customer advocate ,to handle this. someone whom the customer can trust with the confidential information ( could be a direct customer rep) AND can speak developer lingo I would make this person responsible and accountable for making sure that development team understands deliverable details.