Michael Kramarenko on Traps of Product Delivery

Problem Statement

“Which problem do we solve?” is arguably the most favorite phrase in the rich arsenal of Michael Kramarenko’s aphorisms; and for a good reason.

As the man stated during his lecture, this phrase is relevant regardless of your professional activity. If you don’t know what problem do you solve for a client, you are on the right track to misunderstandings, questionable strategic decisions, frustration on both sides, and tons of unnecessary work.

For instance, we had an outstaffing project, and for some time, our client was visibly frustrated and unsatisfied. We were not sure what the issue was as the work went as intended, and the price was negotiated and deemed reasonable for everyone. As it often happens, honest communication helped to solve the issue. It appeared that the client had his demo/delivery dates, and when they were approaching he grew increasingly anxious and nervous regarding the deadlines. The solution was simple: a simple process that would keep us updated on the approaching delivery dates so we could help the client to ensure that all the functional delivered in time. The situation stabilized.

Another important point is not to rush from the “problem space to the solution space.” You have to chew on the issue first to understand all its intricacies and depth and only then move on with the solution. Otherwise, you are risking providing a half-baked product/service that does not really cover a client’s needs.

Battle of three armies

Another important aspect of the efficient delivery manager mindset Is to remember the specifics of the business battlefield and the traps it presents for an unprepared participant. The first trap is a battle of three different armies:

– Sales

– Human Capital

– Delivery

Unlike the business theory that claims that a company has a universal mission, values, and vision that employees share, the reality is somewhat different and more competitive.

A company is an entity that consists of various departments each of which has its own KPIs and ways of approaching similar problems.

For example, the sales department, for the sake of sales, gets a project that a company does not have enough expertise to deliver (it could be a lack of required specialists or bench). Now, the delivery department should go to the human capital department and try to figure out how much time it would take to hire the required employee. Human capital gets under sudden pressure to find and recruit so much needed talent ASAP. Such a situation creates a lot of frustrated and stressed out people, so the battle ensues.

There are two primary ways of preventing such warfare:

1) Leads Qualifications. For instance, BANT analysis. The sales department should have an established process for declining leads that do not suit the company.

2) Conduct synchro meetings for sales, HC, and delivery departments concerning important leads.

Nothing fancy, just simple solutions that work.

Hearsay Trap

If you are working with partners, which serve as intermediaries between you and your stakeholders/potential clients, be wary of basing your estimates on their words. Their predictions or analysis of a project can be vague and under-researched. As a result, you can go into a project blind without a clear vision of the future.

If you don’t have direct access to a stakeholder, don’t start a project unless you are entirely comfortable with your intermediaries.

PM Competence Trap

IT community grows fast, and if previously PM ranks consisted mostly of experienced developers who decided to change course, now, there is a lot of people without a technical background. If a newly PM does not want to dive into the technical aspects of IT, it presents an issue because he or she will lack the understanding of details. It presents an even bigger problem if PM creates a communication bottleneck by not providing developers with the possibility to communicate with a client, acting as an intermediary.

Not Paying Much Attention to Transition Requirements

Transition requirements are often a source of hidden scope. For example, you develop a new version for a legacy system, and there is already a sizeable dataset that should be migrated to a new platform. If you estimate such a transition by eye neglecting its complications, you can run into a big problem. Once, Michael’s had a similar bitter experience with a fix-priced project when a superficial estimation predicted 60 men/hours, which in reality, appeared to be 1500 men/hours.

User Story vs Use Case

You should prefer a use case over a user story. Why? There are three primary reasons why a user story is an inferior tool compared to a use case.

– A user story is a language that allows for different interpretations from you and your customer. As a result, accuracy suffers, and misunderstandings happen.

– A user story doesn’t answer the question “How?” while answering only the question “What?” Therefore, if a customer has also a technological vision in addition to a business one, a user story won’t be able to communicate it as effectively as a use case.

– A user story lacks context.

Metrics & KPI Trap

Neglecting metrics and KPIs can be a major trap for startups because the former is among the best ways of figuring out whether the product is viable and if certain corrections are required.

Unverified Assumptions

Developing a project requires making assumptions about some aspects of its functionality. It’s okay if those assumptions are core or agreed. However, there are a lot of hidden or simply false assumptions that people make without paying a second thought to them due to the specifics of their worldview and experience. Such assumptions, if not voiced and double-checked can lead to significant troubles.

For example, a developer assumed that the attachments that should have been implemented to a project were simple PDF ones. He went along with the assumption and estimated that the work would take 60 hours in total. However, the attachments appeared to be meta-information driven attributes linked with any entity in the application.

In the end, the development took 6 months of work, Considering it was a fixed-priced project, the unvoiced assumption appeared to be an expensive one.

Therefore, assumptions should be voiced and verified or rejected.

Performance

Performance checks are necessary to avoid unpleasant situations.

If the response to “How you measure the performance of the web application?” is, “a web page should load in a second or less,” then you fail to properly address performance requirements. The essential thing to take into account is the attack or the maximum number of concurrent users a digital product will deal with. Otherwise, you know nothing regarding the performance capabilities of the project.

In the worst-case scenario, If you fail to address performance analysis properly, the developers will spend months rewriting the system’s architecture so it can handle the load it should.

Availability

Should the online service you develop be available 24/7? Of course, it should?

In this case, always remember that the availability of the service you develop is rarely solely your responsibility. There are factors you simply have no control over, such as a cloud vendor’s SLA, Internet connection availability, technical malfunctions of the servers. And the more complex the system’s architecture is, the more difficult and expensive it is to develop and ensure stable availability and maintenance.

Therefore, you should always be wary when making availability commitments that go beyond your reach.

Conclusions

To conclude, there is a lot of hidden-scope sources, which can result in a significant financial blow, especially to fixed-price projects. As follows, when the deal gets to the facilitation of the smooth software product delivery process, one should always be wary of the following traps:

– A superficial understanding of the issue the product or service solves

– Different goals and vision of sales, delivery, and human capital departments

– Basing the estimates or other assumptions on the words of intermediaries

– PM’s lack of technical expertise

– Neglecting transition requirements

– The inferiority of a user story in comparison to a use case under certain circumstances

– Neglecting metrics & KPIs when developing a startup

– Relying on unverified assumptions

– Failing to properly conduct the performance analysis

– Committing to the availability standards that go beyond your reach

KindGeek is a full-cycle software development company with extensive BA/BD expertise, contact us, and we will help you make your vision a reality.

Mykhailo Bogdan