INFOSYS 220 Chap.6 Design Strategies and Project Kickoff
Design Strategies and Project Kickoff
Choose acquisition strategy from evidence
A design strategy determines how capability will be obtained. A custom build can support distinctive processes, strategic control or requirements unavailable in the market, but it needs development skill, time and continuing ownership.
A package, service or outsourced option may deploy faster and transfer some technical risk, yet licensing, fit, integration, privacy, vendor dependence and change control remain.
The analyst revisits requirements, compares total consequences and documents the rationale rather than treating make or buy as a slogan.
Use the proposal to create delivery discipline
Project kickoff aligns scope, roles, artefact ownership, decision rights and working evidence.
The group proposal is a genuine progression decision: its scope, use cases, GUI choices and professional quality must be credible enough for approval. A prototype can then explore design early, gather feedback and expose misunderstandings before full construction. Numbered functions, annotated screens and a maintained work record make later claims auditable.
What this chapter covers
- 01
Custom build, package, service and outsourcing options
- 02
Requirement fit, capability, cost and strategic alignment
- 03
Vendor, licensing, integration, security and lock in risk
- 04
Low and high fidelity prototype purposes
- 05
Proposal approval as a project progression gate
- 06
Roles, Trello evidence, decision ownership and team coordination
Worked example · free
Compare build and service options
- 2State criteria derived from requirements.
- 3Compare fit and lifecycle consequences.
- 2Address security and vendor risk.
- 1Recommend an evidence step.
Key terms
- Design Strategy
- The justified approach for obtaining solution capability through build, purchase, service or external delivery.
- Custom Development
- Creating software for distinctive requirements under the organisation's development and support responsibility.
- Software Service
- Using vendor hosted capability under subscription, configuration, integration and contractual constraints.
- Vendor Lock In
- Dependence that makes switching difficult because of data, integration, contract or specialised process choices.
- Prototype
- A draft representation used to communicate, explore and test design ideas before full commitment.
- Decision Right
- Explicit authority assigned to a role for making or approving a project choice.
Design Strategies and Project Kickoff FAQ
Is buying always faster than building?
Not necessarily. A package may reduce coding time but configuration, procurement, data migration, integration, security review and process change still take effort. Speed should be tested against the actual requirements and organisational controls rather than assumed from the product category.
When is custom development justified?
It can be justified when distinctive capability creates material value, suitable market options do not exist, or control and security needs demand it. The recommendation must also address skills, delivery risk, maintenance and lifecycle cost. Strategic importance alone does not create development capacity.
What does a prototype prove?
A prototype can test understanding, interaction, navigation and stakeholder response. It does not automatically prove production performance, security, integration or maintainability. State the question each prototype is designed to answer and avoid extending its evidence beyond that scope.
Why does kickoff need decision rights?
Teams lose time when ownership and approval authority are ambiguous. Clear decision rights identify who can accept scope, resolve design disputes, approve changes and sign off evidence. They complement task assignment because responsibility for producing work is not identical to authority for accepting it.
Exam move
Construct a decision matrix from a real set of requirements. Use criteria for functional fit, quality constraints, delivery time, internal skills, integration, security, data portability, vendor viability, support and total lifecycle cost. Define each scale before scoring. Compare a custom build, configurable package and hosted service, then perform a sensitivity check by changing the weight of the most uncertain criterion.
Write a paragraph explaining what the matrix omits and what evidence should be gathered next. For prototype practice, create a question log: every sketch or interaction should answer one uncertainty about scope, navigation, terminology or feedback. Separate evidence a prototype can support from production claims it cannot.
Build a kickoff board with scope, artefact owners, decision rights, dependencies, review dates and a definition of done. Simulate one disagreement and route it through the recorded authority. Finally, inspect a proposal as an approval body would: check consistency between need, use cases, GUI choice, architecture idea and planned evidence. Reject trivial or illegible content even if it looks polished.
This exercise prepares both the make or buy decision and the group progression gate by turning attractive ideas into reviewable commitments.
Working through Design Strategies and Project Kickoff in INFOSYS 220? Sia is AskSia’s AI Information Technology tutor — ask any INFOSYS 220 Design Strategies and Project Kickoff question and get a clear, step-by-step explanation grounded in how INFOSYS 220 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.