Handoffs Don't Work

I recently spoke with a project manager. He was concerned about the product managers handing off the requirements to the development staff.

He was right to be concerned. Handoffs don’t work.  The more people think they are done with “their” part, the less likely you are to receive/finish a great product. That’s because no one can tell what they really want until they see it.

The more often the requirements-generators see the product as it’s being built, the easier it is to modify the product. The more the developers see the testers test the product, the easier it is for them to incorporate that feedback into their development.

A successful product requires everyone to participate fully throughout the whole project.  That means you can forget about people coming off this project to start the next one. That’s because the people who are supposed to come off the project need to continue their work until everyone is done.

Handoffs don’t work. Collaboration does. Keep everyone on the project until it’s really done-done-done.

13 Replies to “Handoffs Don't Work”

  1. Hi Johanna,

    I think the issue here is that the developers should have been “in the loop” during the requirements gathering process… don’t you think?

    If the developers already understood the requirements (by having the opportunity to review, make suggestions, etc) by this time, there’s no real “hand off” that has to happen.

  2. Yes! Thank you for stating it so clearly.

    Hand-off’s bug me. It makes it way to easy to hand-off crud.

    IMO, the product should be a complete team effort, design to customer usage. Something they can own and be proud of. Assembly line, hand-offs, throwing stuff over the wall, leads to a disconnected team with little true ownership of their product. Thereby little vested interest in it beyond a means to a paycheck… (Not that a paycheck is bad, but if all you’re doing is working day to day just to get a paycheck, without at least a little passion and interest, then IT/Development may not be the field for you… so I feel at least 😉

    That’s one of the reason’s I like Agile/Scrum. It’s about the product, about a cross function team, about the goal of delivering a good working solution. You succeed if the product & team succeeds…

  3. “That’s because no one can tell what they really want until they see it.” Sorry, but that is just crap. You might fiddle with “how” something does a task, but knowing “what” is needed can be done, and more companies and their auditors are demanding just that, so it is known what is to be delivered, for how much and for what value before development starts. The problem here is not a hand-off, but the poor quality of the deliverable being handed over. Come to http://www.iag.biz and see how it can be done with the quality that is needed.

    “A successful product requires everyone to participate fully throughout the whole project. ” That’s a luxury the average company cannot afford. As a Business Analyst for 20 years, staying on a project during development does not keep me occupied 100%. Given that and all the next projects waiting to get underway means I will be working on a project for requirements while one to many other projects continue through the lifecycle. If any of those projects needs me, I am there immediately. Working on one project only is un-realistic, multi-tasking on multiple projects is the true reality.

  4. David, so maybe I am guilty of being a little frivolous 🙂 But I wouldn’t simply disregard the point as ‘crap’. Sure a lot of things can be determined at the beginning of the process, but I have never worked on a project where the customer hasn’t had a change of mind on something. Almost always this has been driven by feedback, looking at the results and understanding what it possible. Its entirely possible of course that you wouldn’t see this if your approach is one of hand off – because you are already working on the next project.

    I think the statement that everyone participate fully throughout the project actually means that you would have to be engaged 100% of the time, just that you acknowledge that you are responsible for closing the loop with the customer and the rest of the team. I think that anyone on a project team should feel a sense of responsibility and see themselves as part of the team that is creating value for the customer – from inception to delivery.

    Agree with your point about value – it is pointless getting into a project before determining that the product will be valuable.

    I am interested in your point about poor quality; which deliverables are you referring to?

  5. Hi David,

    It would be nice if you could back up your claims by going back to your customers and have them quantify the value actually delivered. You know a ROI?

    This is the problem Joanna is eluding to, it is very easy to optimise the pieces whilst missing the opportunity to optimise the whole.

    Lets assume that you and your organisation are very good at requirements elucidation. A paper requirements spec delivers no business value at all. Software only has value when it is deployed to production. Lets assume that the development and delivery team is exemplary too, by the time the software has been delivered the business environment may have changed from the one which was the basis of your requirements elucidation. So what is the overall value of the entire exercise end-to-end?

    It is amazing how the software industries perception of itself is very different from the perception of its customers. Most Business Managers I know would rather poke their eyes out with a sharp stick rather than through good money at a software project, never to see a return.

    The world in which our customers live is non-deterministic and chaotic where change is a natural part of life. Now this may not fit our deterministic processes with long delivery cycles and numerous hand-offs but it is their reality.

    Fortunately some of us have hung around long enough into the release and maintenance phases of projects to realise that a determinsitic approach to new product development just doesn’t work. This realisation breeds a certain degree of humility where you take smaller steps with frequent releases (1 to 3 months), being sure to deliver real business value with each release and relying on real world feedback (like an actual ROI) as a guide.

    This type of humility is totally lacking in your comments.

    Paul.

  6. Hi Andrew,

    I think you were right the first time 🙂 On a project that is releasing real business value (working software) once a month then the BA would be engaged 100% of the time. Her time would be fully utilised gaining qualitative and quantitative feedback on past releases whilst defining the requirements for the next release.

    For a project large enough to warrant a BA then this is a full time job. For smaller projects then the BA role could be one of many roles adopted by a single individual (a team lead perhaps). The point though is that the person doing the work should be fully engaged.

    How else will they be able to give this important role the focus it deserves?

  7. Paul, good point, bad terminology ‘engaged’. My assumption was that the person that played the role of BA would still be on the project, just they would not necessarily need to spend 100% of their time doing the same thing. My feeling is that its you’re not assuming responsibility for a project if you don’t see it through. Think we’re on the same page.

  8. Poor quality deliverables? I am talking about Requirements that are incomplete, incorrect, unverifiable, untestable, contradictory, unclear… The measure of quality is when the business sees the deliverable and says “yes, I will pay for that” and developers see the deliverable and say “yes, I can build that”.

    Delivery cycles? Three months is optimal. Go longer and enough change will occur to cause “thats not what I need now”. Go shorter, and you will disrupt the business too often with implementations that interrupt actual business operation. Most business works on quarterly cycles, so should IT. Use of good artifacts does not mean long delivery cycles, too big a scope at one time does that.

    Return on Investment? How can you estimate costs and benefits at the start of a project without sufficient definition of Requirements? As you proceed, is a good architecture and design also value-less?

    Of course, the other place to take this conversation is that 75% or more of IT projects don’t produce new systems, they are maintenance and enhancements. And lots of the remaining 25% don’t deliver new software, they implement packages or services. All of these projects still need Requirements though, so we need to be able to create a quality deliverable every time.

  9. David, I don’t want to do this one to death, and I suspect we are veering off topic so here’s my last comment on the issue.

    You don’t sound like someone who has ever had to deliver real working software to a customer, so this might sound a little radical. Requirements aren’t deliverables.

    Try to put yourself in the shoes of a customer and think for a minute – what is it that they want? Do they want half a rain forest in the form of beautiful documents and images? Since you work in a consultancy, its likely that you are engaged on the basis that you deliver documentation – but that is not the goal! Someone, somewhere actually wants a piece of real software to help their business make money!

    It is never possible to put together requirements that are 100% complete, correct, verifiable, testable, consistent and clear. If you stay behind on a project after you have delivered your documents and start talking and listening to developers, you will quickly realize that. What you have is a snapshot in time that does its level best to achieve all the things in your list, but you’re not accounting for the fact that things always change. Besides that, the inherent complexity of most projects means that mere mortals cannot forsee every little detail, this especially applies to customers who are far more concerned with the big picture. I am guessing that NASA is probably the one organization on earth that may have come close to 100% on any of those attributes, but they have the budget, most businesses don’t.

    You cannot generalize on delivery cycles. Surely the answer here is – it depends. For some businesses it may be abolutely the right thing to do, but you cannot and should not try to adopt a one-size-fits-all philosphy.

    Largely I agree with your statement about ROI and definition of requirements at the start of the project, but our thinking probably differs at the detail level. The best way to determine what will really happen is use an empirical, feedback driven approach, we can go into details another time.

    Finally, I never said that architecture and design were value-less, they are a critical part of any project and all good developers recognize that.

  10. Twenty five years working as an employee at insurance companies, express companies, loan and lease companies, I have delivered many,many working systems to business areas that needed them, as a programmer and a business analyst, and a PM and tester when resources were short….and most of them were packages: mortgage loan administration, IT Chargeback systems, individual life insurance systems, express delivery status websites, human resource systems, …from single spreadsheet macros to enterprise-wide systems… plus R&D on Structured Methods, Information Engineering, Object-Oriented, SOA, Business Rules, Business Process Management, Data Warehousing…

    It is never possible to put together requirements that are 100% complete, correct, verifiable, testable, consistent and clear? Never say never; just because you have not seen it done does not mean it is impossible.

    …so, I don’t believe you will change your mind on this; if you are truly succeeding with your methods, then power to you, but that does not mean that others cannot succeed with a different approach, if they know what they are doing.

Leave a Reply