Defining Your Unqork Project: Scoping, Application Considerations, and Complexity
Robust scoping is the single most important activity for guaranteeing successful delivery of your applications. Good scoping prevents "scope creep," ensures the project stays within resource boundaries, and quickly delivers tangible ROI. It also allows you to perform proper due diligence and prevent retroactive fixes due to missing requirements, compliance considerations, role based access pitfalls, and more.
This guide provides the preliminary steps necessary before development begins, and explains how to think through application complexity to scope appropriately, assist in team identification, and begin to estimate delivery timelines.
Preliminary Scoping Steps: Defining the Quick Win
Before any configuration begins, your Unqork Champions (Business and Technical) and Business Analyst must lead the following discovery process to define a clear, achievable scope. This is a topic that extends beyond Unqork and can be applied to other tools, coding languages, and general SDLC frameworks. You can (and should) use your preexisting knowledge to scope your applications and achieve success.
Define the Core Objective ("The Why")
Start with a single, clear problem statement. What specific business outcome must this application achieve? (e.g., "Reduce the time it takes for new employees to request access to internal systems.")
Action: Write a single, concise sentence that defines the primary goal of the application. If the objective is broad or vague, the scope is too broad.
Map the Current State Process
Thoroughly understand the current process the new Unqork application will replace. This helps identify bottlenecks and non-essential steps that can be eliminated.
Action: Map the flow using a simple flowchart: Input -> Process -> Output. Document every data input, decision point (approval/rejection logic), and required system interaction.
Identify Key Users and Personas
Identify every person who will interact with the application.
Action: Define the "who." For each user group (e.g., 'Submitter,' 'Approver'), list what they must be able to do, what data they must see, and what access permissions they require.
Define the Scope Boundaries (In-Scope vs. Out-of-Scope)
This is critical for managing complexity. You must be disciplined about what the first release will not do.
Example:
In-Scope: Only the core business logic, single-level approvals, and 1-2 primary integrations.
Out-of-Scope (for now): Multi-language support, complex financial reporting dashboards, integration with non-essential legacy systems, or high-complexity features (potentially deferred to a later phase).
Understanding Application Complexity
After Initial discussions and investigations we recommend using our application considerations document to formally classify the project as Low, Medium, or High complexity. This classification will help determine the required resources, project and team structure, and can eventually help estimate timelines as your team gets more experience estimated timeline.
Here is a high level overview of some primary complexity considerations. However, this is a starting point and not a definitive representation of exactly what separates application complexity and resourcing mix. These are highly dependent on a number of factors, many of them external to Unqork, that your team must consider before beginning application delivery such as internal architecture, timelines, buy-in, difficulty of integrations, and more.
Low-Complexity Applications
Low-complexity applications are ideal for a newly enabled team building their first application. They must be focused, quick wins designed for rapid time-to-market.
Integrations: Ideally simple data fetches (GET) or simple data pushes (POST) to 1 or 2 integrations. Complex data transformation should be out of scope.
Application Workflow: A linear process (A -> B -> C) with a single approval gate.
Governance: The team must introduce formal project management and begin sharing best practices.
Team: Can be managed by the Unqork Champion and 1-2 Application Engineers (Creators), with Specialist roles covered by the Engineers or the Champion. If the champion does not have architecture experience, a Solution Architect must be included as well.
Medium-Complexity Applications
Moderate-complexity applications are appropriate after the team has successfully delivered 1-2 quick wins. They require greater discipline and a more formal team structure.
Integrations: 2 to 5 integrations, including more complex service calls and simple data mapping/transformation.
Workflow: Includes more complex branching logic and 1-2 hierarchical approval levels.
Governance: The team must introduce formal project management and focus on driving the success and efficiency for the organization.
Team: Team begins to expand to allow specialist roles covered by a full or partial full time equivalent (FTE). A Lead Application Engineer should also be assigned to allow coaching and proper task assignment.
High-Complexity Applications
High-complexity applications are large investments, usually replacing core systems or managing critical customer-facing transactions. They require an experienced team or a fully mature Center of Excellence (CoE).
Integrations: 5+ mission-critical integrations, potentially including batch processing, microservices, and complex API orchestration.
Workflow: Complex branching logic, multiple levels of approval, multiple roles involved in the approval process at different points.
Governance: The team must have formal project management in place and experience with all the organization's architecture requirements. Having enterprise governance experience here is critical.
Team: Requires a robust team with 2+ Lead Application Engineers, teams of distributed Application Engineers, a Solution Architect, and support staff
Key Scoping Outcomes
A successful scoping process yields concrete artifacts that confirm the project's viability and set up the development team for success.
Confirmation of Complexity
The final scope must be measured against the considerations found in the following article. While every team and organization is different, it is generally recommended to align complexity with the maturity of the team and work through lower complexity applications before moving up to mission critical high complexity applications.
High-Fidelity Requirements
At the end of the scoping process your team should have a clear, unambiguous list of functional requirements, technical dependencies, and user experience expectations. These serve as the direct blueprint for configuration.
Estimated Level of Effort (LOE) and Timeline
Based on the confirmed tier, the Unqork Technical Champion and development team should provide an estimated timeline.
Defined Acceptance Criteria
Establish clear and measurable success metrics for the initial release. This often involves defining what "done" means for the business and technical stakeholders. (e.g., "The approval process must be reduced from 3 days to 3 hours.")