Project Timeline
- Sample project timeline.
- Varies based on type and size of project
- Includes System Design and Business request timeline.
Timeline (8 months example)
Planning Timelines
Timeline estimates for success and business/management comfort levels.
- Notes:
- This is highly variable based on complexity, staffing and other factors.
- It's a very rough guesstimate to use as an outline only.
- Highly complex or low-staffed apps may take longer.
- Assume delays - requests often change and new obstacles may appear.
- Do not underestimate. Do not use "best case". If pressured on time estimates make a column for best case (what you are pressured on), as well as more delayed columns of different scenarios.
- Better to ask for more time upfront, rather than after missed deadlines.
Timeline estimates
Including business, UX, systems architecture, development.
Type of app
- POC (Proof of concept): shorter than these timeline numbers. 1-2 months.
- Simple isolated backend API/DB-only app: pre-existing database, API, and/or backend. Shorter than these timeline numbers. 2-3 months.
- Templated MVP apps: previously templated app, customized and quickly deployed. Shorter than these timeline numbers. 2-4 months.
- MVP (Minimum Viable Product): in line with these timeline numbers. 4-6 months.
- Complex multiple API/DB-only, multiple data sources: In line or longer than these timeline numbers. 4-8 months.
- Multi-platform POC or MVP: Inline with or longer than these timeline numbers. 6-8 months.
- Replacing high-traffic existing app: longer than these timeline numbers. 6-12 months.
- High dependencies or very low dev staffing: longer than these timeline numbers.
- Complex Machine Learning or Big Data/Compute app: longer than these timeline numbers.
- Gaming, Virtual Reality, Complex Graphics app: longer or much longer than these timeline numbers.
- Enterprise-wide high risk application: much longer than these timeline numbers.
Time estimates
- 1-3 months: normal for lower-complexity feature/s in an existing app. (low-average complexity/staffing)
- 6-12 months: typical for a small to medium-sized (complexity) enterprise app.
- 4-8 months: often the ask for smaller ones, higher-end for medium+ complexity.
- 4-6 months: realistic for less complex apps.
- 6-12 months: realistic for medium complexity.
- Problems can cause it to slip to 12+ months.
- Don't forget to plan post-launch resources staffing too!
- Larger app can take as much as 1-2 years.
- Major enterprise, largest apps can take 1-3 years.
Timeline
caution
- This is a general guideline and sample only.
- You should adjust and vary this based on your team's expertise, app type and the situation.
6U kickoff (from 0-2 months)
As an architect, we need to get the basics of the app and help form requirements.
- Architect Request - Initial 6U to gather info/requirements
- 6U: User Story, User Roles, User Qualities, UI, UX, User Growth
- Architect is "in the loop" on marketing decisions impacting the requirements.
- Architect available to answer high-level tech-related questions.
Counting from Days Remaining on the project Timeline goal:
| Days | Systems Design Tasks | Business Planning Tasks |
|---|---|---|
| 240 | Initial 6U info request | 6U, idea mapping |
| 230 | Advise | Market/cost feasibility research, surveys |
| 210 | Project backlog, Advise | User marketing research ongoing |
| 200 | Prioritization | Feature ideas, docs, UX |
UX Design, Market Research (to 3.5 months)
- Business plan should be coming together.
- Architect is available, assisting if needed for functional requirements.
- Often there are pivots, new requirements and changes.
- Some system design prep is ok if confidence is high.
- Nice: rough idea and confidence of basic systems decisions already.
- Red flag: disorganized and/or vague/impossible requirements, conflicts.
- Architect "Sanity Check" soon-- validate things are on track.
- No architect presentations yet. (a lot can change still)
- External dependencies and timelines considered, well in advance.
| Day | Systems Design Tasks | Business Planning Tasks |
|---|---|---|
| 180 | Architect advice | UX meeting, features, design |
| 160 | Systems diagram prep | UX meeting, features detailed |
| 150 | 6U revisit, detail, clarify | Feature ideas, market testing done |
| 140 | Quantify dependencies | Resolving dependencies |
Functional/Non-Functional docs, Systems/UX (to 4.5-5 months)
- Business plan is complete and should be fairly stable ideally.
- System Architecture Design and diagrams can go forward
- Collaboration with Tech lead and/or senior devs.
- Loop in SMEs, specialists, devs who will be implementing, for heads-up, buy-in
| Day | Systems Design Tasks | Business Planning Tasks |
|---|---|---|
| 135 | Systems architecture (start), Tech lead | Marketing/UX (ongoing) |
| 125 | Systems architecture (ongoing) | Marketing/UX document |
| 120 | Systems architecture presentation, Tech lead | |
| 115 | Systems diagram/docs, Tech Systems review |
Review and Resolve (to 5-6 months in)
| Day | Systems Design Tasks | Business Planning Tasks |
|---|---|---|
| 105 | Tech/Mgr validation | Business Systems review |
| 100 | Resolve any issues | Resolve any issues |
| 95 | Resolve any issues | Resolve any issues |
| 90 | Contract | Contract |
Realize (to 6-9 months in)
| Day | Tech/Systems Tasks | Business Planning Tasks |
|---|---|---|
| 90 | Realize, schedule w/tech lead | Marketing/Business misc. |
| 75 | Dev 1 UI | Marketing/Business misc. |
| 60 | Dev 2 UI/BE setup | Marketing/Business misc. |
| 45 | Dev 3 UI/APIs/DB Backend/QA | UI Approval, Support docs |
| 30 | Dev 4 APIs/Backend/QA | Backend Approval, Marketing docs |
| 15 | Dev 5 DEvOps/QA | Devops |
| 10 | UAT/Final Validation, launch checklist | Final Validation, launch coordination |
| 00 | Launch | Launch approval |
Post-launch - Limited Availability
| Day | Tech/Systems Tasks | Business Planning Tasks |
|---|---|---|
| 00 | Limited Availability | Launch approval |
| +2 | Advise - Logging, Fixes | User feedback/testing |
| +5 | Advise -Small iterations | Marketing/Business misc. |
| +10 | Full availability | Full approval |
| +10 | Advise - Alerts, logging dashboards | Marketing/Business misc. |
| +15 | Advise - Stretch release work | Marketing/Business misc. |
| +30 | Advise - Stretch release | Marketing/Business misc. |
Typical systems by risk-level
For informal reference (not a strict definition):
Major Feature
- Multiple UI/backend grouped functionality changes with a good amount of code and risk.
- May be promoted to leadership/internal/users and so may have tech and user risk.
- Standalone, may be only one or two developers, no fulltime UX designer, one stakeholder.
- If grouped with other features, may have more risk and be a full application.
- Usually only brief initial consultations with architect.
- Risk-level varies based on case, high to low. High for system-critical, but often lower priority.
Small Risk Application
- Multiple features grouped into a distinct and united UX/backend system.
- Typically smaller, less complex and lower-profile than larger apps.
- Usually a few developers or less.
- One shared or no architect
- Risk is moderate, mainly to the team/department
Medium-Large Risk Application:
- Multiple major features grouped into a distinct and united UX/backend system.
- Has many other dependent people/groups internal or external.
- Company contracts, other projects, etc. may be impacted.
- High visibility. Important internally and/or with user awareness/dependencies.
- One shared or dedicated architect
- Risk is high to team, department, small company.
Large-scale High Risk Application:
- May involve multiple applications, and a dozen or dozens of features.
- There could be 100 people working on this in some way in multiple departments.
- May involve a lot of investment by the company- $5 million+ in staff alone could be low-end, while there could be hundreds of millions or even billions on the line.
- Normally this is heavily promoted, and so has reputation impact company-wide.
- Risk is very high on this application.
Timeline Objections, Answers
- It's important to emphasize shared goals and collaboration when answering objections.
"Why does this architect planning take so long? Isn't it just a simple app?"
- Each technology decision potentially needs to be considered for:
- Usability, scalability, cost, reliability, performance, security and more.
- There are at least 10 major technical components affecting the product.
- (note: these numbers are examples, apps will vary)
- Components are connected in 15 different ways, by different regions/devices.
- Usage has at least 8 different types of usage patterns, external and internal and various other dependencies.
- There are other internal requirements, such as our existing infrastructure integration, compliance etc.
- So that's at least 125+ datapoints/decisions. All could impact the success and quality of the app.
- Decisions are compared for multiple solutions, documented for development planning and signoff and presented.
- That adds up quickly to the timeline given, even if it takes only a short time per decision evaluation.
"Weeks? You should be able to make a diagram in a few hours! I could do that!"
- The diagramming part is only organizing and connecting boxes on a screen to visualize the previous research and solutioning. Sure this can be done very quickly.
- 95% of the solution architect's time is not diagramming. It's evaluating, comparing, investigating technologies and how they work together and then developing a solution that makes is best and customized for the given request.
- The part that takes a long time is evaluating each of those for the many factors involved to ensure success, quality, extensibility, scalability, security, usability and more. (see above)
- The final results are represented in simplified form by the visual diagrams.
- Think of it like looking at the dot of New York City on a map. The map with the city name and dot is not explaining how it works or much of any detail.
- As far as the architecting cost in time?
- If it breaks or requires a total redesign a few months from now how much will that cost in re-development, re-architecting and user inconvenience and dissatisfaction?
"We don't have that much time to wait for the project to be completed."
- The length of the project is necessary to ensure that the final product is of high quality and meets all of the project's objectives.
- We can also discuss ways to potentially accelerate certain aspects of the project while still maintaining quality.
"The longer the timeline, the more expensive the project will be."
- A longer timeline may result in initially higher costs, but it's important to consider the long-term benefits.
- Investing more resources now can lead to cost savings in the future, and should lead to a final product of higher quality.
- We can explore ways to control costs, such as negotiating with vendors or exploring more cost-effective solutions.
"Our competitors will beat us to market if the project takes too long."
- Rushing the project could result in a lower quality product or even failure.
- Let's focus on identifying and implementing key differentiators that will set our product apart from the competition.
- Let's explore ways to potentially launch certain aspects of the project before the completion of the full project.
"The timeline will not meet our customers' needs."
- It's based on the priorities related for meeting all of the project's objectives and addresses the needs of our customers.
- We can also explore ways to gather customer feedback incrementally during the development process to ensure users there needs are soon to be satisfied.
"The timeline is too long, and it will not meet our internal deadlines."
- We can discuss ways to potentially align or change internal deadlines with the project timeline.
- Let's explore ways to accelerate certain aspects of the project while still maintaining quality.
- Priorities can be shifted or changed, we can reevaluate them.