Custom Software Development and Engineering

Four Documents We Deliver On Every Project When people need to understand your project, it's more than just code they'll need

Deliver clients a strong set of documents that support their project now and into the future


Four target documents that cover a wide range of project needs

Regardless of whether your project approach is derived by plan-driven methodology such as waterfall, RUP or Spiral or the Agile-based approaches such as XP, SCRUM, or DSDM, documents shouldn’t be a secondary thought when running your project.

“Unfortunately project methodology misuse can lead to gaps in documentation that hurt not just the project but also the organization into the future”, stated Justin Ribeiro, Chief Executive Officer of Stickman Ventures and 22 year software engineering veteran. “If you overgeneralize the approach, what’s really happening is you're simply skipping necessary work.”

What an organization can expect for a given set of documents will largely depend on the scope of what a project might entail. At Stickman Ventures, you’re guaranteed at the very least four documents we consider essential for ongoing success regardless of a project size, methodology, or timeline.

JUMP: Justification, Utilization, and Methodology Proposal

Projects start with the identification of a particular need or problem that a client may have identified in their organization. This could be for any numbers of reasons, from shifts in the industry standards, growth in their respective company or changes in the way their competitors do business. Regardless, the need for a document to encompass this need or problem starts at Stickman Ventures as the JUMP document.

JUMP, defined as justification, utilization, and methodology proposal, helps us create a rounded business case that a manager or executive can use to help convince their respective superiors or board of the pending need for a project. Derived from meetings, observations, and research, the goal of the document is non-technical in nature.

“Software engineers and developers are going to focus on the technical justification, which while important, isn’t the start point most of the time,” said Paul Perrone, a product manager at Stickman Ventures. “JUMP is our means to relay and verify to our clients ‘this is what you’ve told us, here’s the case to be made’”.

JUMP can include a wide range of information, from CMMI Level 5 style innovation project headings, to larger economic analysis, to goal breakdowns. The goal is to give you a solid footing to make a solid decision.

BEIA: Best-Effort Incremental Architecture

Software today is not in most cases built in a vacuum; integrations with other services and firms, along with a changing deployment and scale all need to be taken into account as software reaches the architecture phase. To help, we produce a BEIA, defined as best-effort incremental architecture.

“The goal of BEIA is to address the need for a documented, forward thinking systems architecture while acknowledging that business moves fast,” said James Duvall, Chief Architect at Stickman Ventures. “Given phased or sprint style incremental features that may change in priority, we want the arch to handle that growth with as little churn as possible.”

BEIA is a living set of documents in most cases, maintained so that team growth or the addition of engineering resources understand the current system and how it operates with little to no guess work. Covering everything from data models to load balancers, BEIA is a clearinghouse for understanding of any projects technical aspects as a whole.

Requirements and Specifications

When it comes to project failure, the research is clear that taking a laissez-faire approach to requirements and specifications is a poor business choice. Nearly 25% of project failures can be attributed to poor scope and specifications as defined by the Standish Groups ongoing studies.

“Determining requirements is time and labor intensive even before we’re often on the scene to help”, noted Paul Perrone, product manager at Stickman Ventures. “The push is always to start the project yesterday, but we are diligent in documenting not just want is being asked of us, but what we see as the process that we’re trying to build for or within.”

Our requirements and specifications come in a wide range of styles. From RFC style SHALL documents to Customer or User Story style, our goal is to document what not only what you want but how that requirement fits into the larger scope of work.

Code Documentation

Documented code may seem like a run-of-the-mill document that does not have a high value in comparison to others, but it’s an integral part of everything that we build and ship.

“We didn’t know just how valuable that code documentation was until we started expanding and our partners wanted to integrate with us,” said Chris Hansen, chief executive officer of Bricks and Mortar Media LLC. “We were able to move faster because of the upfront planning Stickman Ventures did.”

Stickman Venture utilizes the proper documentation formats for the language used, allowing standard tools such as Sphinx, DoxyGen, GoDoc, JsDoc and more to provide up to date documentation generated straight from the codebase.

“I’ve lost count of how many projects we’ve inherited that have zero docs”, said Walter Kuppens, software engineer at Stickman Ventures. “No inline comments, no code style guide follow, no proper doc auto-generation; they’re just a mess and it requires so much additional time to get to an LOE [level of effort] for a new feature.”

Tip of the Iceberg

With every project being different, the expanding array of documents that Stickman Ventures produces is ever changing.

“There a lot of documents we produce that probably aren’t going to make the top four”, said Duvall as he prepared for a conference call on a Wednesday morning. “Timelines, risk estimates, ROI/CBA, you name it. It would be a very large list.”

Many others agreed with Duvall, stating that the while the reasons vary there is one defining goal when it comes to Stickman’s approach to documentation.

“Our goal is to make sure that the next person or team who looks or has to work on a project we developed is not in the dark”, said Ribeiro. “There is nothing worse than playing detective when the clock is ticking on a new release.”

Ready to start?

Get in touch. We're ready to listen.