How to manage Software projects with an intermediary?

Question

When a company gets outsourced by a non-software company, the main issue comes when requirement acquisition is going on. For example, client company will look up to an Advertising company for a mobile app creation. Advertising company outsource the development on a software company.

Needless to say, Advertising company doesn't know a proper way to manage software lifecycle (as requirements, client feedback, etc), and the results are unsatisfied clients.

Is there an standard procedure to successfully manage projects when you're working with an intermediary, that isn't just "Well just do whatever the intermediary tells you to", but actually gets you to solve the intermediary's client problem?

With your answer consider how do you manage communication with the client (do you tell him you work for the intermediary company, or you're partners), acceptance criterias, client feedback, any other concept you can think of.

Answer 1

It's a very common situation and a very tough challenge. An agency works very differently from a software company, and many, many projects fail with the model end-client -> creative agency -> software company.

I have worked for a number of years with agencies trying to solve this exact problem, and while I certainly haven't found a silver bullet, I can share some of what I've learned:

Lifecycle model

You probably do not want to use an agile model with agency projects:

• Usually, the project scope is small enough to be better managed using a standard, sequential lifecycle model.
• Agency clients overwhelmingly prefer fixed-price projects, which is hard to provide with an agile life cycle.
• Agile projects require a lot of end-client involvement which you are unlikely to get from agency end-clients. The agency might also want to completely hide the fact that they use subcontractors, meaning you can't facilitate the agile process.

Of course you can use agile development practices, but the typical SCRUM lifecycle model should be avoided in most of these cases.

Communication with end-client

Together with the agency, decide early on if the software company will deal directly with the end-client or through the agency's project- or account manager. Usually it will be the latter. In many cases the end-client won't even know you exist.

Specification

If you are a software company, don't take on projects without a thorough specification. The agency will be used to very short "briefs", which are too simplistic to base a software project on.

• You'll need to educate the agency PM on what is needed in the spec.
• Be prepared that the spec will take longer than usual to produce.
• You are the vendor and the agency is your client - it is your responsibility that the spec is of sufficient quality. Work with your client to produce a good spec.
• Get the agency to get an approval on the specification from the end-client.

Estimations

Agencies and agency end-clients commonly have little understanding of estimates. This is one of the hardest points to communicate. An agency will think it entirely reasonable that a graphic production estimated at 8 hours ends up to take 16 hours. But if a development effort of 200 hours end up taking 400 hours, they'll not be understanding at all, even though it's the same percentage overshoot.

I usually give a 20 minutes presentation, where I show stuff like the "cone of uncertainty", discuss the yearly Standish Chaos reports or otherwise try to explain that estimation in general is wildly inaccurate, hopefully in examples they can relate to. You should also only deliver estimates with clear indications of the uncertainty and risks.

Day-to-day management

• Allocate more time in the project plan than usual, to project management.
• Talk to the clients on the phone as often as you can.
• Be prepared to explain concepts like deployment, environments etc. Be very clear about what a test environment is! (I once had an agency allocating data-entry personnel to work on the test environment without my knowledge. The test database got wiped weekly.)

In summary: Be prepared to educate the client and take some hard discussions, when you hit subjects like estimations. In general, it's a hard model but the good news it that projects can usually be delivered successfully if the software company does a bit more intensive project management than usual.

Answer 2

Your situation

Your client has identified a business case that they believe is worth spending money on: Creation of a mobile app. The client has engaged with the Advertising company who has probably promised the moon. Then, the Advertising company sub contracted the software development project to your software development firm.

The problem

Unless your client has tasked strong business leaders to handle this project, there's a good chance that the client doesn't understand what they want, much less articulated that to the Advertising company. If you "just do what the Advertising company says", you may get your paycheck for this project, but you could also be setting yourself up for failure.

This situation is one of the areas with Agile software development can be very effective. Here is how I would approach it.

Step 1

Go to your point of contact at the Advertising company and explain to them, "The better we help the client understand what they want, the more happy they will be with the product we deliver. To make sure that we are delivering the right product, our software developers (or a representative from our software developers) need to engage directly with the client. Both your company and mine will have a more satisfied customer if we can approach this project using Agile software development principles. The first step towards that is to establish a product owner team that consists of you (the Advertising company), the relevant decision makers from the client, and my software development team. The product owner team should plan for a long first meeting to initially establish and prioritize the backlog, then we should have (1, 2, or 3) week sprints to present what we've developed and continue to refine the backlog."

Step 2

When you have your first product owners team meeting, you have to quickly educate the team on why it is important they spend time doing this and what that team's purpose is: create and prioritize the backlog. In other words, you want the product owners team to dream up every feature that they could possibly want. The team can think in term of "epics" or big ideas. Then, get the product owner team to prioritize their epics. Once the client has identified a number of epics AND prioritized them, then let your software team can start to dissect the epics that were ranked the highest. Don't let your technical team get into details - or "how we are going to accomplish this" - too soon. In the beginning, while you are still creating your backlog, keep it high level. Once your backlog is made, then you can start to get down into the weeds - but only for the highest rank epics that you are going to tackle in the next sprint or two.

Tips and References

Likewise, a tip from my experience, as you begin the project, focus on UI first. Non-coders can't visualize what it will look like. It's better to show them a non-functioning UI than no UI at all.

When you are contracting for a company, implementing Agile using SCRUM tactics has been the most effective for me (versus Kanban or waterfall). I love making people go through this series just so they can get the basics. Then we tweak it from there... http://scrumtrainingseries.com/