Tag Archives: project management

Reaching the end of the road. Or not?

In an ambitious hardware development project, it is very common to achieve a situation when the end of the road seems to be at reach: you went all the way through a challenging design phase, and you prototyped a few concepts that you iteratively improved until reaching a good confidence level that all initial requirement can be fulfilled. The project manager at this point has already filled the Gantt chart bar to a comfortable  90%, and already anticipate that tiny shot of dopamine that fires in his brain upon marking the task as “Done“. But here is where the wise engineer cools down the mounting enthusiasm:

“Yeah, we do see the end of the road…but perhaps there is a river in between”.

I heard that in a meeting today, and it struck me by lightning. For once, because I  happen to be in that very situation!

It was July 2014, and I was on a off-road trip in Iceland with my father and my brother. We were driving a well equipped off-road vehicle, a Land Rover Defender with snorkel and oversized wheels: the kind of vehicle that you need to cross the mighty inlands.

iceland land rover defender
The mighty Land Rover Defender. My favourite car.

Despite Iceland is quite famous for its off-road itineraries, there are plenty of paved roads, which for a Defender’s driver are evil, as gravel roads would be for a Ferrari. So we tried to take, whenever possible, detours that would bring on gravel and muddy stretch of roads, where we could enjoy the childish fun of driving full-speed through mud pools, and crossing small ponds and and creeks.

land rover defender iceland
Crossing small creeks with the Land Rover Defender in Iceland.

In one of these outings, we drove four hours on a challenging road among lava fields and the kind of rocks that do not make good friendship with your tires. The wether was chilly and the sky covered with gray cloud, from time to time dispatching a bit of their liquid load. According to the GPS, we were approaching the end of the road: a T-connection bringing us again on the main paved road and thus, in few minutes, to our next camping destination.

Doesn’t it sound a bit like when at the end of a long engineering study, after you went all the way through troubles and obstacles (and if you are a real engineer – like a real off-road driver – had a lot of fun doing it), a solution seems to be at reach? Well…

I tell you: there was indeed a river – just few hundred meters from the main road connection. And a big one! And there ain’t any bridges for God sake!

So what do you do? Go back all the way to the starting point?

My younger brother sent to check the river depth before crossing.
My younger brother sent to check the river depth before crossing.

What’s the analog of the river in the engineering world?

Suppose you had to prototype a certain electronics subsystem. You devised concepts and selected them after careful tradeoffs. You picked up couple promising ones, and made a design, schematics, and layouts. You ordered PCBs and expensive electronics components, and spent days populating prototypes, and testing and debugging them. On the way, you had to cross several creeks and mud pools: once you solved a problem here, you opened another there. That quick and dirty prototype, was definitely not quick, but you rather became very dirty along the way.  Problems emerge wherever you would least expect them. Eventually, you end up with a 90% solution that fulfils all but one requirements. And there lies the manager’s bias: to consider that the end of the road is at reach.

When the engineer is asked by the project manager “what’s the progress”, he rightfully replies 90%. And he is right: he ended up in a local minimum of the whole solution space to the problem under investigation, which is 90% as deep as the global one. The problem is that the global minimum can be just slightly off the current spot, or miles away (like it can happen in chemistry in the optimization of complex molecular structures).

Never forget that a river may be hiding just behind the last turn and you  will avoid one of the most common project manager’s pitfalls .

That is my lesson learned for today. And if you are curious to know how it ended up with my small off-road adventure: eventually, we sent my younger brother on ahead in the freezing water of the mighty river to check the depth and the stability of the bottom. That’s what they write on the off-road driving best practices after all. There was some pretty big rock along the way. A bit of a bumpy drive, but we made it in the end. And it was definitely a lot of fun!

river crossing defender iceland
Here we are! Job done!


The art of contracting for agile project or product development

The trend towards agile project management poses quite some challenges when such practice has to be framed in the context of a contract with a third party.

All in all, remember that the goal of the contract is still to deliver a working product: get rid of all the waste that diverts the focus from delivering real value!

Let’s take scrum as an example (but most of the considerations below are applicable to the rest of agile methods). At first sight, its rules seem to be at odd with the typical situation of a contracted work where, simply speaking, one party defines what it needs, and the other promises to deliver it for a certain price. To some extent, scrum refuses to define beforehand the complete and detailed definition of what has to be done. Instead, it assumes that the scope of the work emerges fully only through the recursive application of a certain set of rules and habits typical of the specific framework applied. The same rules and habits allow to gradually tackle the work and – by frequently delivering and therefore testing on the field the product increments – to ensure alignment between the planned work and the true needs of the customers.

Now, a typical lawyer would probably snigger at the ingenuous agile practitioner who asks him consultation to devise a contract that can support such a situation as I have described above. He might point out that, although in an ideal world things might happen as agile implies, in practice that is not often the case. Therefore, one has to setup a strong focus in the contract on nailing down the key elements of the prospected endeavour, and clearly defining what is the nominal path of the contract execution and all the possible deviations to it. Eventually, this may influence and distort the execution of the work to the point that agility may remain only a statement of good will rather than an actual practice.

Recently, I found a very good resource – agilecontracts.com – that helped me draft my first agile contract in the context of an early study for an hardware (subsystem) development of a mass spectrometer for space exploration. I definitely recommend going through the full material available on this website to anybody seeking practical advice on how to setup a good agile contractual framework. Not only it provides very practical advise on contracts drafting, but also it introduces quite nicely how to deal effectively with lawyers at all stages of the contractual relationship.

From the first part of the Agile Contracts Primer, I have summarized my takeaways on the topic on the little learning journal that follows, either summarizing my own reflections on the topic or extracting the most relevant statements from the text. I will come back on the topic in the future, with some more practical insight on the topic from my work experience. I look forward to hearing your thoughts on the topic in the post comments! 😉

  1. Number one priority shall be the delivery of a successful project, NOT of a successful contract.
  2. Successful projects are not ultimately born from contracts, but from relationships based on collaboration, transparency, and trust.
  3. Law is usually behind the curve and not ahead of it, because of the very nature of how law develops. Expect to find old contract models reused and adapted to new problems.
  4. Agile Manifesto‘s third principle “customer collaboration over contract negotiation” is not a dichotomy. The manifesto goes on saying “while there is value in the items on the right, we value the items on the left more”.
  5. Collaboration shall be expressed not only in the contractual language, but also in the behaviour of the parties (including lawyers) during project execution.
  6. Beware of contract clauses that are inherently incompatible with agility. For instance, those forcing to define and sign-off all requirements before starting implementation.
  7. Astoundingly, surveys have shown that “scope and goals” has not been among the major lawyers concern in contract negotiation. Between 2002 and 2011 “scope and goals” did not make the top 10 of IACCM rankings, but it jumped surprisingly on at the 4th place in 2014, perhaps after somebody made them notice there was something wrong with it. Interestingly, “limitation of liability” has been consistently 1st priority in contract negotiation from 2002 to 2014.
  8. As a traditional saying goes: “You have a good contract when both parties are unhappy“. Beware of the lawyer that pronounce it.
  9. In case of problems, the parties have the tendency to refer to the contract and work towards local optima: in such case, try to think to the larger impacts of your choices and to be guided by the higher-level goals of the system.
  10. Measurements and incentives lead to local optimization. For example, if the legal department is rewarded on the basis of legal outcomes, there may be fewer legal issues (local optimization), but not greater project success (global optimization).
  11. If you need to refer to the contract during its execution, that is already a sign of failure.
  12. “Time spent on any item of an agenda is invesely proportional to the cost of the item – C.N.Parkinson’s Law of Triviality”; and that’s true as well for the terms that are being discussed in a contract negotiation.
  13. The frequent delivery of working product increments dramatically reduces the risk in an agile project, and consequently lowers the pressure on negotiation exhaustingly certain contractual terms (while in a traditional waterfall approach, there is usually a long delay before project deliverables, which injects fear and anxiety in the negotiation).
  14. The liability to stop the project at any iteration in an agile project (e.g., 1 month-long sprint) should imply less pressure on clauses of liability and indemnification.
  15. An agile project DOES NOT aim at building partial components of the product iteratively, bur rather it aims at building a deployable working model (with gradually more functionality) of value to the customers that can be accepted and used  at each iteration.
  16. In a sequential-development project the focus is on gathering all requirements upfront, and articulate every possible case and testing to meet the anticipated requirements. Such upfront requirements risks to be ill-conceived or lack effective engagement with real users, and after the delivery of a system that conforms to the contract, one may still need new requirements to meet the true needs.
  17. Contracts that promote or mandate sequential life cycle development increase project risk.
  18. Agile principles can protect a client from things they may not know.
  19. Agile recognizes that money may be better spent for requirements that were not recognized at the beginning.
  20. There are three general areas of concerns when drafting a contract, and an agile approach is generally better at avoiding the problems that lawyers are worried about:
    1. Risk and exposure (liability) > Agile reduces the risk because it limits both the scope of the deliverables and the extent of the payment
    2. Flexibility to allow for change > Agile allows for inevitable change
    3. Clarity regarding obligations, deliverables, and expectations > Agile focuses negotiation on the neglected area of the delivery
  21. The ongoing collaboration between customers and supplier required for an agile contract shall be enabled by a contractual construct that facilitates it without the need of frequent involvement of a lawyer.
  22. Evidence-based management research shows that incentives lead to dysfunctions such as increased gaming, and reduction of transparency and quality (see for example the great Pfeffer and Sutton book Hard Facts, Dangerous Half-Truths, and Total Nonsense: Profiting from Evidence-Based Management).
  23. Penalties connected to performance variation lead to similar problems than incentives.
  24. A successful contract models may be “share the pain  or gain” (whatever form this could take in your specific case).
  25. In scrum, definition of done obviates for any deliverable list!
  26. Involve, seek feedback, and engage early on the legal professional (as well as all other actors and stakeholders) for a true application of Agile Manifesto’s third principle.
  27. All in all, remember that the goal of the contract is still to deliver a working product: get rid of all the waste that diverts the focus from delivering real value!