I have a saying, "Projects always win." It does not matter how you manage them, or how you approach them, the inherent stress and difficulty in bringing a project to production leaves physical after effects with the team; psychologically as a team and physically as individuals.

I recall many years ago doing a project in telecommunications where I was working between eighty and one hundred hours a week for an extended period - the dreaded software 'crunch'. Because it was all billable I billed every hour to the client. My paycheck each fortnight was 2.5 times what it normally was and I thought I was rich; however as soon as it went into production my body gave out and I was sick for the next two weeks. Projects win.

More recently we did a project that had us doing eighteen hour days through the QA period to production; I survived it better than normal due to my fitness regime but I was tired, like a robot, and carrying cold sores at the end of it. For the software team it took two months to shake off the tiredness effects of the project. There is a significant loss of productivity during that period.

The toys always come out at the end of the project and it is a way that we make up for the damage we do to our physical health. I bought my second Corvette the day my energy project went live. I was antsy the whole time during the purchase process as I was waiting for a doom and gloom phone call about it being in production and something going wrong. I can recall the car salesman being confused about my behavior.

My current Corvette I bought at the end of the Gravy Project for the same reasons. That team at the end of the project bought Corvettes (me), Lexus', House', Lotus', etc. The psychological desire to buy a toy or an extravagance of some kind at the end of a project is undeniable. It is how we keep ourselves up for the next project. Otherwise the stress is not worth it.

I recently read Sharon Moalem's Survival of the Sickest. In the back of the book he makes the comment to a question that the field of Psychoneuroimmunoendrocrinology [PNI] has sprung up to study phenomena such as why the body gets sick after a particularly stressful time. Moalem writes:

They [PNI Scientists] realize that from moment to moment every emotion we have is registered by most, if not all, of the cells in our bodies.

It is a reductionist view of emotions, but given my empirical experience with software projects, IMO, one that will bear fruit. Modern project management, even when done well such that there is no crunch period, or abject stress on team members (which is possible our last project was done on time and with the standard working week) still leaves physical and psychological residue on the team. It will be interesting to have that kind of effect mapped to immunology and the other physical medical sciences. It might even be able to answer why 'projects always win'.

Bill Scott [Netflix] comments on the differences between user experience or interface designers and the engineers which implement those designs:

Design teams feel finished when they have produced a comp and the necessary graphical assets. But the interface engineering team is just starting their work. The trick is to get interface engineers involved much earlier in the process and to get designers to stay engaged throughout the full production cycle. Engineers are production focused. Designers are often ideation focused.

I treat the Product/UE as Engineers customers. It is my job to say yes to their designs and implement them. Too often engineers think they are experts in UE and should determine how a website behaves or looks. This is incorrect. US is a specialist profession that collects data empirically through focus groups and user experience labs. User Experience professionals, while understanding technology, do not tell engineers what technology to use. The inverse should be true too.

There are limitations in the customer approach, a large being that technology cannot always implement the designer's vision. In those instances I have the engineer work directly and intimately with the UE designer to get something that will achieve the design and user experience goal within the limitations of the technology, system or whatever other engineering restraint we are facing. This has worked excellently and helped to raise the level of satisfaction in the final product that Product/UE and Engineering have.

I agree that designers need to be involved in the entire process, even though one of the downsides is the spec document tends to remain volatile and informal until the final weeks of the project when it is handed off to QA. Having the designer and engineer work together to get a feature honed will remove some of that volatility.

The other mechanism to dampen spec volatility is to treat the whole process as informal until the feature complete milestone is reached. After that point the project formalizes with a finalized spec, formal test cases and engineers hands off on feature and only engaged in quality improvements and bug fixes. By that point Engineering's customer changes from Product/UE to QA where the deliverable is feature complete and working code.

By that point features are the last thing on Engineering's mind as the codebase is put into a mode of dampening to that it can be packaged and readied for release.

The alternative to that method is to fix the spec before the project starts and make concrete scoping from that. This is great for marketing as Engineering will not commit to the project until it is absolutely certain it can do it, and that the project can be completed in the scoping provided; but really, that sucks for both designers and engineers; and projects do have to have a cowboyish element to them in order to have fun with your job.

I enjoy betting on our guys, and I enjoy telling Product/UE we can do it, or that we will have a go at it, and if we cant do it, we will work with UE to come up with something that will solve their user experience issue. This approach works well, produces strong products and is an enjoyable manner to work.