Seamless Success: A Delightful Journey with your Client on IT Projects

Simply put, the Project Scope is the ‘what’ of a project — its ‘guts’, so to speak. And the Scope is the fundamental and primary handshake between the requester and the developer.

Seems pretty straight-forward, right — the scope communicates to the project team what the client is expecting. In many cases, the seeds for failure are frequently sown right at the initial stages due to several key factors; namely, the lack of understanding of the context and business rationale at the organizational and/or a departmental level, and/or a lack of understanding of the client’s pain-points. It is imperative to ask the questions “What is the problem that is being solved?”

One of the skills of a great a leader lies in the ability to expand the scope into a more comprehensive set of clearly defined robust set of deliverables. The set of deliverables is one of the key success factors and will provide direction for the entire project thus maximizing its chance to succeed. Developing user stories or use cases will help define the deliverables more fully.

Another risk new projects face is the rush to deliver! Many of us work in an “I want it yesterday!” work environment or company culture. Clients want to ‘see stuff’. What I am talking about here is asking the right questions at the outset of the project in order to get a fuller more detailed picture of what the client says/thinks they want.

Both scope creep and scope change can go unnoticed, unidentified, and untraceable IF the starting point (i.e., the defined scope) is not holistic, complete, and highly detailed. However, the additional time spent upfront asking the ‘why’ and understanding critical business pain points that the project is attempting to solve will save considerably more time in the long run!

What does ‘Done’ mean to the client? Project teams seldom ask this question and assume we know. Defining the acceptance criteria of each feature or functionality is a must in order to determine completion.

Lastly, if the scope is too large to break into clear-cut deliverables, consider dividing the large scope into smaller scopes but each with its own set of clear-cut robust deliverables. When a large scope of work is broken down into sub-scopes with their own set of deliverables, the results will usually lead to a happier client, in part because this delivers results sooner rather than later. In my experience, dividing a large scope of work into smaller pieces has led to a more fulfilled team as well. Smaller and more frequent wins will keep your team and your client happy and engaged!

Key Take-Aways:

• Ask the question “What is the problem that is being solved?” and really understand the fuller picture of what the client wants.

• Understand the business context and specific pain points from the client’s point of view.

• Divide the scope into a set of deliverables taking into consideration the user stories or use cases.

• If scope is too large, break the scope into smaller units of work and then come up with deliverables for each unit of work. This strategy will help show tangible results early with predictable cadence sooner.

• Define “Done” and align with the client for each feature and functionality.