Chapter 1: To execute project initiation

Project initiation is the foundation for successful software development projects in Kenya's dynamic technology sector. It involves defining what the project will achieve and setting clear boundaries to prevent scope creep, which is a common challenge in software projects. Properly identifying the project scope and deliverables ensures alignment between stakeholders such as software developers, clients, and end-users, enabling efficient resource allocation and timely delivery of quality products. This chapter focuses on executing project initiation by detailing how to identify the project scope and determine project deliverables specific to software development environments.

1.1 Identification of Project scope

Project scope is the agreed list of work that must be done to deliver a software product, together with a clear statement of what will not be done. Identifying it is the first real task of project initiation, because cost, time, staffing and testing cannot be estimated until the team knows what it is building. Example: a small software team is asked to build an ordering app for a restaurant. Without a written scope, the owner may assume the app will also run staff rosters, while the developers plan only a menu, an order screen and a kitchen display. The mismatch appears after weeks of work, as extra demands, delay and argument. This is called scope creep: the slow growth of a project's work beyond what was agreed, with no matching increase in time or money. A well-identified scope prevents it by giving every person on the project the same picture from the first day.

Two meanings of scope are used in software projects. Product scope describes the features and qualities of the software itself, such as the screens, reports and speed. Project scope describes all the work needed to deliver that product, including design, coding, testing, training and handover. This topic deals with both, starting from the components a scope statement lists and then the process that produces it.

1.1.1 Key Components Listing

Every scope statement is built from the same set of components. Listing them in a fixed order helps the project manager check that nothing has been left out and gives the client a document that is easy to read and approve. The components are the goals and objectives, the deliverables, the inclusions and exclusions, and the constraints and assumptions.

1.1.1.1 Project goals and objectives

A goal is a broad statement of the purpose of the project, the change the client wants to see. An objective is a specific, measurable result that shows the goal is being reached. A goal is reached through several objectives, and every feature in the project should be traceable to at least one of them.

Example: a shuttle company wants to move seat bookings from a paper register to a phone app.

• Goal: Make seat booking faster and more reliable for passengers and booking clerks.
• Objective 1: Allow a passenger to reserve and pay for a seat in less than three minutes by the end of the pilot month.
• Objective 2: Remove double booking of seats from the first day of live use.
• Objective 3: Give the manager a daily sales report without manual counting.

Objectives written like these can be tested when the project ends. How to write them in the SMART form is covered in Identification of project objectives, so this topic only records them as the first component of the scope.

1.1.1.2 Deliverables

Deliverables are the tangible outputs the project must produce and hand over. In scope identification, the team lists them at a high level so that the client can see what will be received. For an online bookshop project they might be:

• Working application: the web store and its mobile version, installed on the client's hosting.
• Source code and database: the code repository and a database with its structure documented.
• User guide: a short manual for shop staff who process orders.
• Test report: evidence that the main features were tested and the faults found were fixed.
• Training session: a practical session for the people who will use the system.

The difference between deliverables used inside the team and those handed to the client, and the steps for determining them in detail, are taught in Determination of Project deliverables.

1.1.1.3 Inclusions and exclusions

Inclusions are the features, users, platforms and activities that are inside the project. Exclusions are the things that people might expect but that the project will not provide. Writing exclusions down is as important as writing inclusions, because many disputes come from unspoken assumptions about what was included.

An exclusion is not a permanent refusal. It means that the item is not part of this project and that, if the client wants it later, it will be handled as a change or as a separate project with its own time and cost.

1.1.1.4 Constraints and assumptions

Constraints are limits that the project must work within. Assumptions are conditions that the team believes to be true when it plans, but has not yet proved.

Common constraints in a software project include:

• Budget: a fixed amount in Ksh that must cover developers' time, hosting, licences and testing devices.
• Time: a fixed date, such as a launch before the busy tourist season for a lodge booking system.
• People: the number of developers and testers available and the skills they have.
• Technology: the programming language, database or hosting the client already uses and will not change.
• Legal and policy requirements: for example, any system that stores personal data of customers must follow the Data Protection Act, 2019.

Examples of assumptions:

• The client will give the team sample data and test accounts within the first week.
• Users have smartphones that can run the app and can reach the internet.
• A client staff member will be available to answer questions and approve work each week.
• The hosting service chosen will stay available at the quoted price during the project.

Constraints are known facts, while assumptions are guesses that carry risk. Each assumption is written down with the name of the person who will confirm it, because a wrong assumption, such as poor internet at a produce collection centre, can force a change of design in the middle of the project.

1.1.2 Scope formulation process

Scope formulation is the process of turning a client's request into a written scope statement that every stakeholder has accepted. A stakeholder is anyone who is affected by the project or can affect it, such as the client, the sponsor who pays for it, the end-users, the developers and the testers. The process has four stages carried out in order: review the needs, document the requirements, define the boundaries, and confirm the scope.

1.1.2.1 Review client or stakeholder needs

The team begins by finding out who the stakeholders are and what each of them needs. A client's first request is usually a short sentence such as "we want an app", so the team must ask questions until the real needs are clear.

1. List all stakeholders, including the people who will use the system every day and not only the person who signed the request.
2. Choose ways to meet them: interviews with individuals, a workshop with a group, observation of the current way of working, or a study of existing forms and reports.
3. Ask what problem the system must solve, who will use it, how often and on which devices.
4. Separate real needs from wishes, and note which ones the stakeholders consider most important.
5. Record disagreements between stakeholders, for example when the salon owner wants fast booking and the receptionist wants detailed customer records.
6. Summarise what you heard and return it to the stakeholders to check that it was understood correctly.

1.1.2.2 Document the project requirements

The needs found in the review are rewritten as requirements: clear statements of what the software must do and how well it must do it. Documenting them gives developers and testers something exact to build and check.

• Functional requirements: what the system does, for example "The system shall let a customer cancel an order before it is accepted by the kitchen."
• Non-functional requirements: how the system behaves, such as speed, security, ease of use and availability, for example "The order screen shall load within a few seconds on a mobile connection."
• Identification: each requirement receives a unique code so that it can be traced to a design, a test and a deliverable.
• Priority: each requirement is marked as must have, should have or could have, which helps when time or money is short.
• Clarity: each requirement states one thing only and is written so that a tester can say clearly whether it has been met.

The result is usually a requirements document or a requirements list kept in a shared file that all stakeholders can read.

1.1.2.3 Define project boundaries

Boundaries mark the edge of the project: which users, features, systems, locations and phases are inside it and which are outside. The team compares the requirements with the objectives, the budget and the time available, and decides what the project will deliver now and what is left for later.

The decisions are brought together in a scope statement, a short formal document that contains:

• the goals and objectives;
• the deliverables;
• the inclusions and exclusions;
• the constraints and assumptions.

Boundaries also include the systems the new software must connect to, for example a courier firm's existing customer list, because the work of connecting to an outside system must be either inside the scope or clearly outside it. A boundary that is vague, such as "the app will support payments", must be made exact before approval, for example by naming which payment methods are included.

1.1.2.4 Confirm scope with stakeholders

The draft scope statement is not valid until the stakeholders have checked and accepted it. Confirming the scope protects both the team and the client.

1. Send the draft to the stakeholders before the meeting so that they have time to read it.
2. Hold a review meeting and walk through each component, asking whether it matches what they expect.
3. Record every question and correction, and update the statement.
4. Ask the project sponsor or the client's authorised representative to approve the final version in writing, by signature or by an email that clearly states acceptance.
5. Store the approved statement where the whole team can find it, as the scope baseline.
6. Agree that any later change to the scope will be written down as a change request, assessed for its effect on time and cost, and approved before work starts. The way changes are managed in detail is part of project planning.

The scope baseline is the approved scope against which progress and changes are measured for the rest of the project. If a stakeholder asks for a new feature after approval, the team compares the request with the baseline. If the feature is not in the baseline, it is treated as a change request and not as part of the agreed work.

Chapter Summary

This chapter focused on executing project initiation by first identifying the project scope, which involves outlining key components such as project goals and objectives, deliverables, inclusions and exclusions, as well as constraints and assumptions. The scope formulation process requires reviewing client or stakeholder needs, documenting requirements, defining project boundaries, and confirming the scope with all relevant parties. Determining project deliverables was explored by distinguishing between internal and external deliverables and following steps to identify key outcomes, break down tasks, define milestones, and clarify acceptance criteria. The chapter also emphasized the importance of setting clear project objectives using the SMART criteria to ensure they are Specific, Measurable, Achievable, Relevant, and Time-bound. Preparation of the Project Initiation Document (PID) was detailed, highlighting its key sections including purpose and justification, scope, deliverables, objectives, stakeholder analysis, project organization, timeline, budget, risk assessment, and quality management. Lastly, the chapter underscored the significance of the PID as a foundational document that guides project execution and aligns stakeholder expectations from the outset.