team members

All posts tagged team members

A Rotten Way to Create Anything

Posted by tropicaltheartist on February 16, 2015
Posted in: Thoughts. Tagged: , , , , , , , , , , , , , , , , , , , , , , , , , , , , . Leave a comment

giuseppe-cuzzocrea-E5kBdpQ7kQw-unsplash

Abstract:  Under-estimation in technical projects is chronic and widespread.  It arises from bad beliefs and behaviours.  The consequences of under-estimation harm both projects and people.  It also causes under-delivery of promised project features.  It is wiser to choose to properly estimate and fund complex enterprise and development projects.

Yesterday, I had lunch with a dear friend and colleague, for the first time in a decade, who I have known for close to fifty years.  We’ve been good friends, man and boy, but have lived in different countries for several decades.  At one time, I worked for him, in the IT department of a tertiary educational establishment.  Throughout most of our working lives, though, we’ve experienced the world of enterprise Information Technology (IT) and of software development from the perspective of different countries and continents.  What astonished us both was the commonality of experience, in our working lives.  There are global factors that appear to arise, no matter where you practice engineering or technical management.  Perhaps they derive from human nature.

What emerged, early in our catch-up discussion, was that we had both frequently worked on projects whose estimates had been approximately one third of that which, as time would tell, were actually required.  Time and again, we both encountered budgets and timescales which should have been tripled.  With this underestimation problem being so commonplace and seemingly ubiquitous, we began to ponder on why it might be that estimates were so often risibly low and what the knock-on consequences of that perpetual error were.  It was an interesting and far-ranging discussion, drawing on our decades of experience in the industry.

The problem with ludicrously low under-estimates is that the technical and people problems you must solve, during any technical project, must be solved no matter what, or else the project delivers nothing.  There is no way to estimate and budget these problems away, by simply declaring them to be non-existent, on paper.  They happen anyway.  The remedial works you have to do mount up and press on the team and project stakeholders alike.

The issues accumulate, assert themselves and demand answers, which cost time and money.  If there is no time and money available for these unexpected, but wholly predictable and easy to anticipate issues, then other sacrifices are inevitably made.  Usually, the sacrifices involve demanding donated personal time, from those working on the project, or else the deliverables are decimated, resulting in a less than satisfactory outcome for the project’s sponsors and end users.  The opportunity costs, associated with addressing unbudgeted additional tasks, are particularly high.  While you are spending the project budget on fire-fighting or rescue missions, you aren’t using that funding to create needed functionality.

When things go wrong, during a technical project, you have to fix them.  If you don’t fix them, nothing works.  If you do fix them, you need to spend time and money that hasn’t been allocated or budgeted for.  The robbery required to fund the remedies usually takes place at the expense of the people working on the project, or on the delivered functionality.  In the case of a minimum viable solution, taking any functionality away from the deliverables runs the very real risk of causing the solution to be non-viable.

It has to be said: the main cause of under-delivery is under-budgeting, most of the time.  Peter is robbed to pay Paul and then people wonder why Peter is unhappy.

So, why do professional, educated, experienced people perpetually make these hideously silly under-estimates and why are they accepted as immutable gospel?

We both agreed that there is an over-zealous willingness to make “acceptable” promises to project stakeholders and sponsors, which is to blame for chronic under-estimation and hence under-investment in technical solutions.  At the first sign of disapproval, the estimates are reduced.  This is understandable in a hierarchical power-relationship, where the person with the more powerful position (usually the one with the money) can hurt the one making the estimates, if their pronouncements are met with disbelief; feigned or born of ignorance.  The terrible fact is that project sponsors can and do hurt people that steadfastly defend realistic project estimates.  They always want them to be lower.  They are prepared to dispense harm until the estimate they want is the estimate they get.

It is only once that these estimates sound musical to the ears of the sponsors that they become frozen in stone.  The other terrible fact is that, even if the estimator agrees to a musical-sounding, acceptable, low estimate, the practical impossibility of delivering to that estimate will also cause the estimator to be harmed by the project sponsor.  From the point of view of the estimator, you are going to be hurt, whether you low-ball the estimate and fail to deliver on it, or else stick to the realistic estimate, which your experience tells you is the true figure, but displease the sponsor with the discordant sonic nature of your projected numbers.  The duress is merely delayed, in the case of offering a derisory under-estimate.

Project sponsors, for their part, are usually mired in debt and cash flow precarity.  Their imperatives to call for low estimates are born of fear and desperation and a naive belief that software comes from thin air.  They wear their lack of insight into the technical development process as a badge of pride, citing their specialism in money matters as a justification.  It’s a form of wilful ignorance and arrogance and leads to very bad decisions, when it comes to funding technical development.  Their every decision, related to sponsoring technical development projects, is, by necessity, based on hearsay, gut feeling and guesswork.

Younger, more thrusting career ladder climbers see advantage in estimate disputes.  If they are trying to score points and win the approval of superiors, in order to get ahead, they will make extravagant promises of being able to do something for nothing.  If they have credibility, the sponsor will gravitate toward the nirvana-like lies, rather than be supportive of more rigorous, fact-based analyses.

What the young go-getter is rarely aware of are the consequences of their seemingly attractive guarantees.  They’re heedless of the terrible downstream ramifications, which in reality nobody wants.  They are also oblivious to what their promises will require them to do to innocent other people, many of whom are the very creators of the technological solution that everybody depends upon, in order to make good on their impossible pledges.  They’ll end up being hated by everyone and hating themselves.  The psychological damage related to this turn of events cannot be underestimated.

Of course, at the point of the inevitable, predictable outcomes rearing their grotesque heads, not a single person that placed pressure on the estimators to deliver a low estimate will be willing to take responsibility for them.  That particular badge of dishonour is usually placed squarely on the technical team and their commitment and competence called into question.

With this turn of events being so common, it is little wonder that my friend and I have not advised our respective teenage children to pursue careers in technology.  We wouldn’t want them to experience the trauma, as interesting and fulfilling as creating things from scratch can be.

Agreeing to under-estimates sends out a broadcast message, throughout the organisation, that technical work is not valuable or to be valued highly.  It casts the aspersion that the technical developers are lazy, good-for-nothings who perpetually sandbag and pretend the work is much more complex and difficult that it really is.  Of course, in reality, the reverse is true.  Technical developers are dedicated and diligent, working far harder than most of their non-technical colleagues, to deliver work that is far more complex and difficult than even they themselves will publicly admit to their colleagues.

One of the drearily predictable and inevitable consequences of under-estimates is that if you are replacing a number of custom-built, bespoke systems with an enterprise-wide, common platform, individual groups, who once had their perfect system, which did everything they wanted to do, the way they wanted to do it, will lose sometimes vital functionality, as it is sacrificed to meet the needs of the dwindling project budget.  The reason they cannot keep their old, bespoke systems is that the organisation cannot afford the maintenance costs on all of these peculiar, vertical solutions.  Only an enterprise-wide, horizontal suite of software makes economic sense.

However, because of under-estimation, they lose utility, when things they once had fail to materialise in the new system rolled out.  The vociferous backlash, coming from system users who are no longer able to do their jobs in quite the same way as they used to be able to, cannot be underestimated, either.  It can bring a change management programme to its knees.

The fundamental problem is that estimated development budgets seldom seem to include the research or maintenance and solution evolution costs.

Firstly, there is scant acknowledgement and recognition of the need to find out what the development team doesn’t know and to learn it, before the work can be accomplished successfully.  There seems to be a preference to pretend that everyone on the team knows everything they need to know already, at the inception of the project.  This leads to construction of the software with significant and telling gaps in the developers’ knowledge.  Obviously, that can lead to downstream issues.

A reasonably complex enterprise system, once installed and running, is rarely static.  It must be maintained, so that it continues to serve users.  Capacity must be planned, upgrades and patches must be applied at intervals and data must be scrupulously backed up, in the event of disaster recovery being necessary.  The system generally evolves, as the organisation is supports also changes.  Both maintenance and evolution have costs and corners cut, during the initial development of the system, can dramatically increase these costs, which are seldom accurately budgeted for, anyway.  System evolution and extension costs are normally regarded as operating costs, but they are really ongoing development costs.

Technical project funders imagine they can get away with cutting the funding for IT and development projects with few practical effects.  Without being mindful of the fact, often, their mental model is that the software they need will somehow appear, due to diligent programmers working harder, or donating their personal time to the cause, or else that their enterprise system will be miraculously conjured out of the ether, by some form of technical magic which they don’t fully understand.  Such a belief is, of course, utterly nonsensical.  Making anything takes time and effort.  If that effort and time is not paid for, it either won’t happen at all, it will be donated grudgingly and sparingly or else they are expecting people to do real work and create tangible value, for free.

Project stakeholders, who ask developers, already under extreme budgetary pressure, if they can add additional functionality, without additional funding and time, using the incantation that begins with the magic words; “Can you just…?” are particularly frustrating and odious distractions that raise the hackles of any development team.  If anybody asked them to do more work, spending more hours doing it, without any additional pay, funding or deadline extension, they’d be furious, yet they blithely, breezily and happily ask for additional features in the software project, as if they come from a bottomless jar of features, for nothing, in no time.

Once the project funding dwindles and the development team begins to be unfairly seen as obstructive, difficult and incompetent, their work performance is scrutinised minutely.  Their every movement, decision and choice is second-guessed, restricted and commented upon.  These judgements are made, often multiple times, by other people in the organisation, who neither understand what the developers do, nor could do it.  Micromanagement by non-technical managers is thought to be the answer to wringing more software out of less money; the unjustified implication being that the technical team is catastrophically and dysfunctionally disorganised.

Ignorance of how software must be created, for it to have lasting value and low cost of ownership, makes for a very poor project sponsor.  It leads to needless, arbitrary, artificial haste, which is self-defeating anyway.  Pared-to-the-bone staffing levels mean that quality is invariably the first casualty.  Corners cut in testing and quality assurance, the first candidates for cuts, come back to haunt system users in the form of egregious software defects that never seem to get resolved.

This kind of poor corporate behaviours sets up the developers to be permanently on the back foot, fire fighting and under constant, extreme pressure.  Sheer corporate denial of the true costs of development projects leads to corner cutting, short changing the user, making the developers feel bad and to lose pride in their work and in their achievements to date.  It is demoralising and soul-destroying, resulting in a lot of jaded, cynical, burnt out people, who have little residual loyalty to the organisation that has reduced them to this state.  You can’t help getting the sense that people’s parents did not raise them for a working life under these conditions of prolonged psychological stress and social engineering.  It’s the stuff of nightmares.  The emotional and psychological scars are long-lasting.

At the nominal end of the woefully under-funded project (for these projects have a habit of running indefinitely, as the mistakes made have to be patched up somehow, usually by a skeleton maintenance staff), reputations are trashed, pay stagnates, appreciation is never forthcoming, career trajectories are damaged and derailed, stress and depression have been induced, health is damaged and all in the name of delivering something that couldn’t have been built for the time and money available in the first place.

The way that IT and R&D projects are chronically under-funded, poorly run and mismanaged is no way to create anything of aesthetic, technical, business or artistic merit.  It’s a very poor method and model for obtaining utility and growing the value of an organisation.  There’s nothing remotely nurturing about it.

It does make you wonder why anyone with programming or technical talent would want to create anything, under these needlessly Draconian conditions, which arise solely from a fictitious belief that complex, valuable software comes very cheaply.

Patronising Rewards

Posted by tropicaltheartist on February 1, 2015
Posted in: Thoughts. Tagged: , , , , , , , , , , , , , , , , , . Leave a comment

robert-anasch-pzdl6P4Lk60-unsplash

Abstract: Rewarding employees the wrong way can be patronising and demotivating.  It is better to not reward at all, than to reward in demeaning, belittling ways.  Key contributors want meaningful recognition that speaks to their autonomy and significance.  Top-down rewards, only bestowed from on high, reinforce the meritocratic injustices in the company hierarchy and cause discontent.

How do you encourage people to do their best work?  It’s an important question, because excellent work contributions translate into company advantage and better earnings.  The need to reward people for doing good, valuable work would seem to be a straightforward thing, yet the way those rewards are handled can actually have the opposite effect to that intended.  Instead of being a factor in promoting consistently high quality work, it can instead lead to demotivation, dissent and withholding of an employee’s best ideas and contributions.

Traditionally, employee recognition took the form of token spot awards.  These are small amounts of money, awarded for a job well done.  The problem with spot awards is that psychological research tells us they only work when the task rewarded is mechanical, routine and largely brain-dead.  For anything that requires initiative, novel thinking or taking personal responsibility, they fail.  In fact, they cause worse outcomes than no reward at all, for those kinds of tasks.  The implication of the small amount of money awarded is that this is all the employee cares about.  It is an explicit way of calling your best contributors “coin operated”.  That can be demeaning and insulting for those whose vocation gives them a higher, more worthy calling.

Also, the amount of the award can be pathetically small, compared to the impact on the company’s bottom line that the employee’s contribution caused and this is not something that employees are unaware of.  Telling an employee that their “good job” was worth £10 or $10, it doesn’t matter which, when it causes the company to earn an additional million, simply outlines the fact that the employee should be working for themselves, not harder for the firm.

Incentives, based on the amount you sell or the amount of profit you generate for the company, are like an unearned bonus, when the orders would have come in, irrespective of your work contribution.  They are relatively easy to scam and they erode teamwork.  They also come to be expected as an entitlement and so, instead of motivating, they merely cause displeasure and dissent, when they are withdrawn or reduced in value.

The other kind of recognition traditionally used is the “attaboy” award.  It’s a token gesture, like sending an e-Card or putting their photograph on the “employee of the month” wall.  Usually accompanied by a fruity and over the top citation, relative to the achievement, the award is both worthless and cringe-worthy, causing embarrassment, rather than pride in a job well done.

Also popular is the share option, which offers the chance of a possibility of maybe earning an indeterminate amount of bonus money some day, if only you willingly submit to inhuman and degrading work practices, or else tolerate excessive top-down management abuse, in order to earn the carrot.  It is an attempt to convince you that you are an owner of the business, who should therefore be willing to make greater personal sacrifices for the good of the business, but an option is not the same as a vested share.  Fully vested shareholders, with voting rights, actually own the business.  Rest assured that the bonus is far from indeterminate.  It has been very carefully determined to ensure that not too much is given away.  In exchange, the employee so incentivized is expected to give their all, sacrificing personal time and relationships, if need be.

All of these recognition techniques can leave the workforce feeling belittled, unappreciated in significant material ways and “owned”, like some kind of pack of good doggies.  If a company’s intention was to encourage their employees to do their best work, there are few things as undermining of that aim as making everybody fully realise their impermanence, replaceability, interchageability and lack of recognised uniqueness, through patronising employee reward schemes.  It’s almost like rubbing their noses in it.

If you ask employees what motivates them, it’s genuine peer respect, autonomy in setting their tasks, assignments and schedules, better conditions, when travelling on business, flexibility in hours worked and place of work, control over their working environment (furnishings, decoration, noise abatement, lighting, comfort), the ability to easily inject their own ideas, innovations and direction into the company’s roadmap, the resources they need to get their job done and realistic, proportionate participation in the good fortune of the company, if their work contribution causes the company’s earnings to rise significantly.  They want to have more of a say on company policy and direction.  When being recognised for their contribution, they want it to be for the things that add purpose and meaning, to the lives of their customers and colleagues, not for things that undermine, destroy, cheat or short-change, as profitable as these might be.  In essence, they want to matter more to the company their work efforts are helping to build and grow, through increasing ownership and to feel genuine pride in their achievements.  How many employee recognition schemes offer that?

On the one hand, companies are fully aware that their value depends critically on the quality of their people and the work contributions they make.  On the other hand, they deny it outright, insisting that the top-down hierarchy is a pure meritocracy, with the earnings, accruing from individual outstanding work, flowing directly into the pockets of upper tiers of management and shareholders, predominantly.  There is clearly a conflict apparent here.  The more that employee recognition rewards are bestowed, exclusively from on high, the more obvious it is that the awarders are not in their positions based on merit.  It becomes quite literally patronising.

Were it the case that the hierarchy really did reflect a pure, internal meritocracy, the most valuable work contributions would always come from the top and it would be obviously the case to all, but this isn’t what we observe.  Just having a recognition scheme that attempts to extract better work from the lower tiers of the organisation reveals the truth.  The top tiers are free-riding.  The things that matter most, to the company, come from people who aren’t in the highest positions in the hierarchy.  Employee recognition has to be a peer-to-peer collegiate thing, or it tends to lose its legitimacy and potency.  Expecting outstanding contributions consistently and returning only crumbs sends a clear message to employees that they are being blatantly exploited and manipulated.  Retention problems and disengagement soon follow.

Employee recognition schemes have traditionally been a system that asserts value comes from the unique contributions of individuals, while the internal organisation of a company, its hierarchy, tells the opposite story.  Few reward effective teamwork.  Whereas employee recognition programmes try to get the most valuable contributions from low level employees, because those things really do significantly affect company earnings, the amount awarded tells the opposite story.  Most importantly, a badly designed employee recognition scheme draws the contradictions into sharp focus, in the minds of those participating.  They cause dissatisfaction and despair, instead of encouragement and motivation.

There is a contradiction between the structures of company ownership and to whom the spoils ultimately go, for the effort and success of the enterprise, versus the reality of where company value actually comes from.  In wanting better company performance, it is imperative for firms to share the resulting success generated by those individual contributions, many of which are turning points for the entire enterprise, more equitably, or their efforts at encouraging superior work contributions will backfire.

Proprietorial ownership of the company, in proportion to the significance of one’s contribution, matters more than money, in most cases, though money is not an insignificant factor.  The best employee contributions cost a meaningful equity stake in the company.  In so doing, the employee gradually transitions from paid hired hand to beneficial owner.  Of course, very few enterprises are rewarding and recognising their employees in this way and consequently, failing to unlock the value that otherwise could be made available to all.  In some cases, that unrealised potential value dwarfs the value of the company, even when taking into consideration the best case growth projections.  Staying in charge and in control is a very costly choice.

What Don’t We Know?

Posted by tropicaltheartist on January 27, 2015
Posted in: Thoughts. Tagged: , , , , , , , , , , , , , , , , , , , , , , , . Leave a comment

dex-ezekiel-fg8tdcxrkrA-unsplash

Abstract:  Development managers often conceal the fact that not everything the team needs to know actually is known (or can be known), at the beginning of a development project.  This leads to poorly designed products and missed deadlines.  Stakeholders are let down and feel deceived.  Developers are punished for other people’s deceptions.  It’s better to state the unknowns, honestly, even if you lose face, because honesty and transparency are paramount and lead to better software development outcomes.

One of the more insidious problems, in development, is intellectual dishonesty.  An architect, or development manager (or team) will be selected to develop some software product, or other, and there will be a lot of the company’s success riding on the outcome of the project.  Everybody knows it’s important and that nobody must be seen to be “difficult” or impeding the project, for no good reason.  The temptation to simply present the development exercise as one of simple, routine execution, based on well-known certainties and a full and lucid understanding of the requirements is immense.  In other words, there is a great deal of expectation that the technical team pronounce the project as “easy” and to offer iron-clad guarantees on cost, feature set, quality and delivery dates.  These guarantees, if given so robustly at the beginning of the project, are almost certainly fictitious lies.

The problem is that if the project is truly worth doing, it will carry some unknowns and risks.  There is little point developing something that already exists, which can be bought, so for something new to be made, there will be things that the development team will have to research, experiment with and discover; maybe a lot of things.  An intellectually honest manager, or software architect, would acknowledge the scope of the unknowns, imagine the best and worst case scenarios and detail them.  Unfortunately, that’s often not what happens.

We all have different experiences and expertise.  Not a single one of us shares the same track record as our colleagues.  We’ve all come from different backgrounds, product developments and technology stacks.  We also all have different interests, as people.  Some care about the details, others are clear on the big picture business drivers.  Nobody can know it all, but the temptation is to pretend you do.  That is pure posturing and it’s ridiculous, because it puts the software project that the company’s fortunes depend on, in peril.  It comes from a deep seated insecurity and a fear of being let go, if you don’t appear to have everything in hand, under control and fully understood, all the time.

Key project stakeholders, also aware of how important the project is to the fortunes of the company, will exert extreme pressure on the technical staff to come up with dates, costs, scope and quality promises they can bank on.  That’s what they need.  Their belief that a technical person can actually give them those guarantees, based on an insufficiency of information, is naive at best and foolhardy at worst.  In some cases, the non-technical stakeholders are merely Teflon coating themselves, in the event that the project doesn’t meet its goals, which given the behaviour of the key stakeholders, it almost certainly won’t.  At that unhappy moment, they’ll be able to point to the technical guarantor of project outcomes and throw them under the proverbial bus.

The technical person often succumbs to the political pressure to pretend to know what all the answers are and what product features are required, or about the problem domain in detail, when they really don’t.  They’re trying to save face and to please the other stakeholders, when the truth is that they may not fully understand the customer requirements, the industry that the product sells into, the competitive landscape, the technology choices for this particular project, the abilities and limitations of their development team members, the peculiarities of the tools they will be permitted to work with and a thousand other variables that can drastically impact cost, delivery date, feature set and quality, no matter how agile the development method employed.

The thing about unknowns is that they inevitably assert themselves, during development.  If the technical staff member has been too keen to nail his reputation to the mast by making unbreakable, non-negotiable promises to the other stakeholders, then as soon as one of those unknowns goes in an inconvenient direction, for him, there is no way to rescue the product launch, the project budget, the reputation of his development team or the business from the disappointments that will arise.  A bloody and brutal death march will result, with developers whipped and flogged, almost literally, to “make up for lost time”, when the thing they were attempting was always going to take longer and cost more than the initial guesstimate promises made.

A good and seasoned development manager exposes what isn’t known, by the team, at the start of the development project and brings any new unknowns to the stakeholders, as they proceed.  They explain to other stakeholders not only what isn’t known, but what cannot be known and how long it will take (and what it will cost) to do the learning and research required to eliminate the unknowns.  This extra time and money needs to be baked into the project schedule and budget at the beginning.  In order to identify what isn’t known, though, some confession will need to take place.

The team members and management will need to be open and up front about what they do not know, even if that exposes a gap in their expertise or experience.  As I said before, not everybody can know everything and nobody knows it all, so stakeholders need to be realistic in acknowledging the team they have, while talented, always have some learning and research to do.  That’s just in the nature of making something brand new, which didn’t exist before.  You literally cannot hire a team of people that know all they need to know to do the job without stopping to learn new things.  If you can, it’s a warning sign that the product you are about to create has no unique selling point.  It has been done before.

Some company cultures posture in a stupid, macho way, belittling anybody that confesses to a need to learn something or to a gap in their knowledge or experience, but that’s a very stupid posture to take, given that it applies to all developers and their managers.  The reality is that people always need to climb learning curves, dig deeper into what they’re being asked to produce and learn about this particular market and customer base.  There really is no such thing as pure development.  It’s a myth.  Every development exercise carries some burden of necessary research.

Agile, as a development method, does not make the research part explicit.  Perhaps that’s why stakeholders think that any team which cannot execute on a product backlog and task backlog, mechanically and interchangeably, is a sign that the team members are incompetents.   If we don’t call out the need for individuals to learn as they develop, then the expectation is set that the job market is full of perfectly trained, fully formed developers that intuitively know everything about your product, customers, competitive landscape and market.  How could that possibly be, unless every developer in the world developed exactly the same products, for the same people, using the same technologies and tools?

These same stakeholders, who will deny funds for developer training, have an expectation that all other firms, in the world, pay generously for people to be trained, or else that the individual developer has so much spare cash and time, that they spend it all on personal training courses.

Take away the shame of being exposed as being without some (considered to be) vital skill, experience, understanding, tool, or piece of information and you open up the possibility of having looser, yet more realistic project budgets and schedules.  While you might not like the added apparent cost, you will like the added certainty that you can plan around a product release date more reliably and may even have time in hand, if things go well.

Once the development team members lose the fear of being called inadequate imposters and of exposing their relative skills gaps, the team can work better together, as a team.  Time can be allocated to go find out what each needs to know.  In some cases, the false economy of hiring junior programmers is revealed, when this step happens.  You realise that some team members need to learn a lot more than others.

Most importantly, team members no longer try to conceal trouble, when they encounter something they don’t know how to solve, or have an incomplete understanding of what they are supposed to be building.  The phrase I have heard used is: “Don’t sit on anything smelly.”  The spirit of this motto is to ask team members to expose unknowns and issues early, when something can be done about them.  The corollary to sitting on something smelly is that it just gets smellier and smellier.

When you transparently and honestly expose to stakeholders what the development team needs to go and find out, before they can set more accurate expectations on budget, delivery time, feature set and quality, you either get the support and permission necessary (what other choice do the stakeholders have?) or else the project is shut down.  People fear unemployment as much as they fear being found wanting in skills and knowledge, so the temptation to lie, to keep a non-viable project going, is strong.  However, the truth always comes out.

A non-viable project reveals itself to be so, at some point, so better to have the stakeholders understand this and make an active management decision, before all the gnashing and wailing, rather than letting the train wreck happen and have to live with the downstream consequences.  If the project is viable and worth doing, then it’s going to be worth getting the development team up to speed with what they need to know to develop it well.  If it’s not, the project should never have been started in the first place.  Too many stakeholders start non-viable projects, on a wing and prayer, with insufficiently deep pockets, and then blame the technical staff for not being able to pull off the required miracle.

It is the responsibility of every development manager and software architect to explain to stakeholders that nobody knows everything and that the people in their team were hired on the basis of being agile-minded enough to go find out.  It is unrealistic and dishonest in the extreme to expect developers to know everything particular to the stakeholders’ business and software code, straight off the street.  It’s time to stop play acting and making promises that nobody can keep.