Have you ever been architected? ...

... I have.  (Sung to the tune of Jimi Hendrix's 1967 track "Are you experienced?")

First let me say that this post does not intend to take shots and enterprise architects or business analysts; we are all in this together.  The aim is to comment on a possible cause for typical complaints with software projects: stakeholders do not get what they expected, when they expected it, and for the price agreed upon.  As a corollary, the software services provider does not make the expected profit.  No one is happy. 

Here is how the story unfolds:

• As the bidder, you get to estimate a project based on a Request For Proposal (RFP) package. This package contains all kinds of information about the client, the stakeholders, the bidding rules, and the requirements. Often the package is fairly vague about deliverables; this is the root cause of the problem.
• Whoever put the RFP together spent a lot of time discussing needs with stakeholders and extracting requirements from those needs. During this process a list of deliverables, think WBS, was discussed. Believe it or not, in some industries the WBS is included in the package, becomes the basis for a fixed cost bid, and later, for progress and financial reporting.
• Stakeholders would have legitimate expectations of having their needs met but they will be disappointed; the “What does done looks like?” question about deliverables was asked but the answer was not properly documented and the bidder is in the dark. The bid package has descended into the minutia of requirements disconnected from deliverables. This is equivalent to ordering a bunch of building supplies (the tasks/features/requirements) but expecting delivery of a bungalow (deliverables); how do the parts relate to the whole? What is the likelihood of satisfaction?
• In response to the RFP you come up with a cost estimate and tentative schedule. Because of the missing deliverables a time and material approach may be suggested even if a fixed cost was requested; this will likely be rejected but, if not, there is a high likelihood of recrimination later in the project.
• The bidder may be told that he is too expensive and/or that delivery is too late. A phased approach may be suggested to clarify the deliverables (time and material phase) and refine the schedule and cost estimate; this is also likely be rejected as it will appear to redo work already performed by the client.

There are ways to avoid or mitigate the problem and its impact:

• You get to engage with the client early on and work as a trusted advisor while the RFP is being created. This may mean that you are not allowed to bid to avoid an apparent conflict of interest.
• Strict gates are applied to prevent the project from moving forward without agreeing that what is being developed is what was envisioned.
• Both parties get ready for very strict scope control.

What do you think?  As always questions and comments are welcome.

Connect with me on LinkedIn.  I am a LinkeIn Open Networker (LION); you can use “Friend” to add me to your network, please mention the blog in your request.

Comments

[Term Paper]

I recently came across your blog and have been reading along. I thought I would leave my first comment. I don't know what to say except that I have enjoyed reading.

[Patrick Richard]

Thanks for leaving such a nice comment. I’ll do my best to keep posting regularly and to provide value. I do get a lot out of this; writing help to focus the mind.