A presentation that is generating a lot of thought and discussion at Protegra is Geoffrey Moore’s presentation on the business of software. If you haven’t seen the presentation yet, you can find it at the following location:
Although the presentation is primarily focused on Software Development and the innovation required to succeed at the business of Software Development, I wondered about how the concepts of Core and Context could apply to projects in general.
To provide a brief recap, when referring to Software Development these are the definitions proposed by Geoffrey Moore:
Core: Processes that differentiate your company for economic advantage.
Context: Everything else.
I believe these concepts of Core and Context primarily revolve around client value. When discussing value for the Business of Software it usually involves increasing revenue for the company in question (Whom is the client). Even innovations are seen as a method to increase the number of clients and eventually revenue. How can we generalize the Core and Context definitions for a project? Here is one thought:
Core: Processes that implement the project for client advantage.
Context: Everything else.
Geoffrey Moore also discusses the concept of items to differentiate versus neutralize. I would propose in a project that both are Core, are required, and can be defined as follows:
Neutralize: To deliver the basic functionality and the project value as proposed and agreed to. Items that neutralize should be continuously evaluated as to whether they are good enough. Waste is defined as spending more time and effort that what is required to achieve the basic functionality.
Differentiate: To innovate to deliver more value than what was proposed and agreed to. Items that differentiate should always be the focus of innovation and never be deemed ‘good enough’. Waste is defined as not spending enough time to differentiate fully.
1. Context versus Core
The Core on the project is only what delivers client advantage. This would be code that implements business functionality, meets or exceeds the business need, and being actively used in production. Everything else is just context. This includes:
- Project Management
- Architecture (usually – depends on the project)
- Infrastructure (usually – depends on the project)
Geoffrey Moore also makes a point about knowing what to focus on and to what extent. Additional effort and cost spent on Context will not return the value that spending that same time on Core will deliver.
2. Continuous Core Innovation
How often in our projects do we focus our efforts and innovation on Core versus Context? I think sometimes I have focused on Context rather than Core in past projects. I sheepishly recall that more of my ‘innovations’ on projects have been regarding project management, documentation, and testing. Context, Context, Context.
In some cases, I think we are almost more comfortable when we don’t have to innovate on Core on a project. Thoughts?
This should be a reminder that we always need to innovate and improve on Core. Not so much to add undue risk to the client, but unless we constantly innovate we are providing less than the maximum value to the client. And if we provide enhanced value to the client, we are certain to have more future projects and differentiate ourselves from the competition.
So do we drop all the Context work we are doing for a project? Absolutely not. Context and Core are both required on every project. These concepts do provide an interesting perspective on just being aware on how much Context we are doing in relation to Core. We should also ensure that we are innovating as much as possible on Core items at all times.
After all, Software Development is a business and if we don’t innovate to provide additional value, someone else will.