The first question we get asked by both leads and clients is how much is this going to cost?

It's an important question as, admittedly, it's one of the foundations of negotiating. The problem is - we have been conditioned to understand this in terms of physical commodities and spatially instituted designs.

There are substantial difficulties negotiating cost in terms of times and evolving priorities.

This is one of the most difficult parts of the work that we do. In short, we need to harmonize industry approved quality standards with an appetite to pay. Perhaps, and most likely, there are economic disciplines that address what we're reaching for - but for fun let's make up some buzz words for it:

1. chronoeconomics
2. evolutionary systems game theory
3. macro, and micro, adaptability for temporal remuneration protocols

...I give up. Having said that, having a framework to understand what a customer is paying for, and having a model to appraise with accuracy seems to be the way forward with dissolving contractual pain points.

🤔 So what does Acorn do?

We start off with a per hour service line agreement to get the ball rolling. We use this time to measure out the final deliverables, and start making inroads with your organization. For the keeners reading this, we use Harvest to track our time by line item.

note: we plan to have a zoom-in feature on images in a later iteration so you'll have to do it for yourself... for now.

Discovery is one contract. Fulfillment is another.

Think about a bridge engineer for a second. What is their job? Yes, they need to build a bridge at the end of the day. At the same time, you can't just ask a bunch of contractors to show up, start digging, potentially blow stuff up, and then put a bunch of metal in the ground and in a waterway.

You need to have a plan.

In the case of the bridge maker, they would need to ensure things like

1. They don't detonate a reef in a protected waterway
2. There are not gale force winds that will turn the bridge into spaghetti
3. They will need to create designs for the bridge that factor in regional environmental variables
4. They will need to understand the who's who of regional stakeholders
5. They will need to create a list of local representatives who can facilitate other things like roads to get to the bridge
6. Then there's alloy chemistry in the saline or non saline water...

The list never ends. One of the biggest 🚩🚩🚩 we see is people confidently throwing around numbers off the top of their head to quote on initiatives they don't fully understand. It works for sales in the short term but...

It is a bonafide pathway to implementation HELL.

The solution is to break entire projects into contractual steps.

In software discovery, we establish several key factors:

1. Who is a stakeholder on the initiative?
2. What technologies will be used to support the initiative?
3. What are the major business objectives?
4. How can we translate those business objectives into scalable software?
5. What are the short, medium, and long term objectives of building the software solution?
6. What stages of execution need to happen that factor in technical details, stakeholder priorities, and overall budget?
7. Who will be responsible for which aspects of fulfillment?

This is where user stories come in handy. Having user stories be developed in conjunction with the provision of multidisciplinary subject matter expertise is where the magic happens. If a client, for example, can assist in providing an organizational objective, a user story is made to support this:

As a shoe salesman, I need to sell shoes at my retail store while listing them on the internet to maximize revenue.

With something as simple as this, software teams have quite a lot of detail to play around with.

• Do you currently use an e-commerce framework?
• Do you have a digital inventory management system?
• How many different types of shoes are you selling?
• Do they come in different colours?
• Would you be interested in networking your brick-and-mortar payment system with the payment processing software on your e-commerce experience?



These are critical details to inform the scope for project execution.

We track foundational element discovery in our time tracking software so we can easily report on the time, cost commitment, and status of an initiative

In being detailed with our discovery estimate, we can tease out fulfillment requirements and send in a second estimate loaded with context.

It is very hard to be thorough with a cursory glance on a complex initiative. By doing our homework first, we can build better contracts ensure project scopes stay on the rails.

Generally speaking there are a few things we search for in our discovery process to inform our fulfillment estimates:

1. Project Stakeholders
2. Existing Information Technology (IT) infrastructure
3. New IT infrastructure requirements
4. Strategic plans for improved user experiences built from reviewing existing site content, user flows, analytics, and more
5. Researching compatible and contextually appropriate software dependencies
6. Constructing paradigms for integrating 3rd party modules into IT environments
7. Creating a high level inventory of required user flows
8. Understanding the 5w's of organizational objectives and drafting high level acceptance criteria
9. Creating order of operations based approaches from research
10. Building a project work back plan in task management software

Again, each initiative tends to be unique, so it's challenging to be prescriptive until we've collected all of the information.

The Outputs of Discovery:

So, our discovery had us forecast major project milestones.

Now what?

Since we're big Jira users, our objective is to build out our "epics" and "boards"

Operational Note: everyone uses these systems differently with their own combos of flare, pizazz, and gusto.

The Epic

Since we have figured out what the heck is going on from a client:vendor lens, we can establish the pillars of project success. These get logged and reported as epics in our project management tools.

The Story

We then have to envision what the constituent blocks of a given milestone would look like. If we reference our custom SEO Modal module, the SEO Module would be the epic, and the steps required to build it are broken down into stories to support this. In our case, we would have broken it down into:

1. Drafting the user flows to support implementation
2. Designing the systems diagrams to understand how to transfer data
3. Designing user interfaces to support this
4. Implementing user interfaces on the back end
5. Integrating the form data from the front end to be stored into the applications database

There are a lot more little knick-knacks and doo-dads that go into a story, but in general we write stories in jira to support the completion of a higher level project milestone.

To rephrase:

We inventory all the component parts of a milestone into stories. Stories, then, house a number of other small pieces that support the completion of the story. A lot of times a thing, broken down in a story, requires participation from a number of different team members or subject matter experts:

1. designing interfaces
2. writing content
3. training client teams
4. writing source code
5. gathering creative assets

All of this needs to be tracked, and fulfilled. To accomplish this, we load up our stories with sub tasks that relate to it.

As you can see, there are a lot of details to draft and break down in a software project that need to be teased out in discovery.

Without due diligence on the constituent blocks of an initiative, we set ourselves up for failure. Without knowing the specifics of the end product, it's impossible to write accurate estimates. Discovery is a necessary step for us to take so we can inform the entire set of project stakeholders on how we plan to get the job done. Finally, discovery is a great exercise to start off with if individuals - or parties - have no prior work experience togher.

Time is money, and accuracy is everything.

Let's put our heads together and get something awesome done. Let's plan it all out in discovery, and provide ourselves detailed instructions to get the job done.