Eight Steps to Define the Vision of a Software Development Project

During the early days of a project, the project team needs to have a ‘compass’ guiding to the effective and efficient achievement of project objectives. It is imperative to create a binding document that defines the project’s stakeholders, and outlines their needs and expectations. Hence, this document becomes the baseline to estimate high-level schedule, effort, and money required to meet stated needs before indulging in detailed requirements. Ultimately, it helps keep the team’s effort aligned with customer requirements and project objectives. This is why a well-defined Project Vision is necessary in any software development project.

The project vision can be tailored to cope with variation in industries and different levels of complexity in projects, yet, all visions share a common purpose. To be effective, the vision document should address the problem to be solved by the project and the benefits reaped from the solution. Since it is customer-centric, it must define customers and stakeholders affected by the project along with their needs. Stakeholders’ needs guide the definition of product features and set the product boundaries (scope) which helps the project team prevent scope creep.

Generally, creating an effective project vision for a software development project involves the following steps:

Step 1: Define the Business Opportunity

Briefly, the project team needs to describe the benefits reaped from completing the project. The project may result in higher competitive benchmark, or the expected annual revenues may be doubled by selling the product of the project. This step is vital to get management’s buy-in and to authorize the project.

Step 2: Define the Problem Statement

The team needs to clarify the problem that the project is intended to solve. The key points to focus on when defining the problem statement are:

  • Problem description,
  • Impact of the problem
  • Expectations of the successful solution

Step 3: Identify Stakeholders and Users

Stakeholder analysis is critical to the success of any project. In this step, the team needs to list all parties that are positively or negatively affected by the project outcome; referred to as Stakeholders. Every stakeholder should be identified along with his/her influence, role in the project, and the mechanism to leverage or mitigate his/her influence.

On the other hand, user groups should be identified in terms of their responsibilities with respect to the system (product), the stakeholder group they relate to, and how they define the success of the solution to be developed.

Step 4: Summarize Stakeholders’ and Users’ Needs

After stakeholders and users have been defined, their needs should be understood and documented. ‘Needs’ can be discovered by understanding key problems the stakeholders experience with the existing system. It is also important to understand priorities, as perceived by the stakeholders, to solve these problems.

Step 5: Develop a Product Overview

The Product Overview defines the scope of the system and its interfaces with external parties. I personally prefer depicting the product overview using the Context Diagram, in which you can define how the system as a unit interacts with external stakeholders and users, and how information flows in and out of the system, from and to external parties.

In addition to showing how the system is related to external stakeholders, the Context Diagram can be expanded to depict the relationships amongst internal system modules. For example, to develop an Accounting System, you can draw arrows between the General Ledger module and the Accounts Payable module to show interaction.

Step 6: Define Product Features

Based on stakeholders’ needs, the project team will be able to develop the high-level capabilities of the system that will meet these needs. Each feature should describe the functionality required in the system to meet one or more of the stakeholders’ needs. For example, a need to quickly approve accounting documents can be met by having a feature of workflow capability to route documents electronically for sign-off by authorized personnel.

Step 7: List Assumptions and Constraints

In this step, the team lists all project assumptions that if changed will alter the project vision. An assumption may state that a specific version of an operating system will be available at the time of installing the system. If this assumption proves false, the vision document may need to be revised.

Besides, the project team should identify all limitations affecting the project. Constraints may be design-related, time and budget-related, environmental, or regulatory.

Step 8: Define Documentation Requirements

Depending on system complexity and customer requirements, it may be required to provide supporting documentation as part of the project deliverables. Documentation includes user manuals, online help, installation guides, and Read Me files.

When the project vision is signed off, the customer and the project team should have a clear vision of the project’s product. This document is the starting point for the Software Requirements Specifications (SRS) in which detailed requirements are articulated to meet the product features. Hence, team members should refer to it frequently to ensure alignment with customer requirements and to prevent scope creep.

Prioritization Matrix: Objectivity in Decision Making

Prioritization Matrix is a decision making tool and is one of the seven management and planning tools used in Six Sigma and Quality Management in general. It is used to determine the best option to select amongst several ones based on specific criteria using numerical values.

Watch this video to know how to create the Prioritization Matrix with Microsoft Office Excel.

Project Leadership: The Latent Power of Success

Increased complexity in contemporary projects puts a heavy burden on the project management profession. Project Managers do no longer have the luxury to be task-oriented only; they need to evolve into Project Leaders in order to bring success to their projects. Accelerating business, environmental, economic, and political changes necessitate the invisible force of running projects, namely leadership, to emerge and save organizations.

A cook lacking the skill to mix the right amounts of ingredients will produce distasteful food even if she has all needed ingredients and cooking tools. And a football team’s couch will drive his team out of a tournament if he does not integrate players’ skills to create the harmony required in the field. Not far from that is the failure project manager whose sole job is to complete project deliverables within given time, scope, cost, and resources without envisioning the project, communicating vision to the team, integrating efforts and removing roadblocks to accomplish the vision.

Effective project leadership has two main concerns; team needs, and project requirements. A successful project leader is one who creates the balance between both concerns and moves forward in achieving project vision. Concern about team needs encompasses understanding each member’s personal and professional aspirations and helping him/her achieve them in line with the project vision. Starting with clear assignment of roles and responsibilities, to assessing member’s abilities and providing required training to accomplish the job, to fully comprehending team evolution dynamics comprise the road map a project leader should adopt to develop the ‘team side’ of her leadership skill. On the other hand, managing project requirements is what brings deliverables to existence. Analyzing stakeholders’ needs, scoping project, managing cost and time constraints, foreseeing risks, creating key performance indicators and monitoring them are the primary tasks a project manager is hired to perform.

Balancing people side and task side is essential to implement a successful project. Excessive concern about team’s needs will not produce deliverables within given constraints by stakeholders, and, on the other hand, neglecting people’s needs while focusing on tasks will demoralize members, tear team apart, and result in a failure project. The right mixture of people and task orientation is what effective leadership brings to project management.

Effective communication remains number one skill a project leader should possess to influence her team and project tasks towards vision fulfillment. Creating a project vision is the beginning of a story that concludes only when vision is clearly communicated, understood, adopted, and accomplished by project team. Although not all team members are required to agree with the vision since it might be impossible, each member must understand the vision and commit to it. Continuous monitoring and controlling to the vision is critical to success. Project leader should keep any eye on vision completion progress and its alignment with stakeholders’ needs and organizational strategy. She should act proactively to adjust vision when strategy and circumstances necessitate that. This can only be achieved by an effective communication plan.

Creating a sense of team accountability is another vital aspect of project leadership. A leader should clearly communicate expectations of members, develop a practical measurement system to evaluate performance, give the team the ability to assess themselves against expectations, and finally develop awards and sanctions limits. Establishing accountability is a hard job to perform by the leader as it requires assessing the current abilities of the team and raising them to perform up to expectations then rewarding or sanctioning members upon evaluation. This all should be done rightly otherwise accountability will incur harmful consequences. If low performers are sanctioned for out of-control factors, resentment will develop and commitment will fall. Similarly, if high-performers are rewarded for out-of-control factors, favoritism will develop and negative conflicts will surface.

Understanding team dynamics and developing the team from individualism to team spirit is the first and foremost priority on the people side of project leadership. Most often team is comprised of members with diverse backgrounds, attitudes, and hidden agendas which make up the recipe of conflicts in projects. Hence, conflicts are inevitable, and project leader should exploit such conflicts to the betterment of the project. Naturally, members cannot evolve to the performing stage immediately. A leader should understand and help the team pass from Forming to Storming to Norming until it reaches the Performing stage in which the team experiences real cohesion and start focusing its efforts to complete project tasks.

By this every project manager needs to explore this invisible critical success factor and assess oneself against various leadership aspects whose absence could doom the project to fail. So, are you people-oriented, task-oriented, or do you create a balance between both? Bring this hidden power to surface and move forward to accomplish your vision.

Work Breakdown Structure Made Easy

“Would you please help me print out this ‘WBS’? It won’t fit in one page. I have a status meeting with the Sponsor in 30 minutes!” a colleague of mine approached me and asked. “This is not a WBS! It is a Schedule in a form of hierarchal structure.” I said sarcastically when I saw her WBS. She listed all project deliverables, and listed all activities below each one. This is not what a WBS is intended to be used for. Does your sponsor or client need to know how you’re going to complete each deliverable? Do you really need to present a 100+ boxes on your WBS to get your sponsor agree on what’s included and what’s excluded in your project scope? Absolutely not.

The primary benefits of having a WBS in any successful project dictate the need to keep it simple. Firstly, a WBS depicts the boundaries of project scope. A client or a sponsor can easily sign off a well-structured WBS as it includes all project scope and excludes whatever out of scope. Secondly, it ensures that effort is not wasted on unnecessary or out-of-scope deliverables. That is, if the WBS lists a redundant Work Package, this would require extra resources, time, and cost. Finally, a good WBS can be used on a project dashboard to communicate scope (changes) without confusing stakeholders with scores of activities needed to complete deliverables. The latter point is actually the key to build a good WBS. A WBS does not include activities; it only lists deliverables down to the Work Package level. Leave listing activities to the Project Schedule. WBS is composed of tangible deliverables without activities whereas a Schedule describes all activities required to complete those deliverables outlined in the WBS.

From another perspective, a WBS represents the project lifecycle that is different from the PM Process Groups. WBS is not used to chart Initiating, Planning, Executing, Monitoring & Controlling, and Closing of a project. These are process groups that describe how you manage a project from start to end but not what the project includes and what it excludes (scope). On the other hand, a project lifecycle describes the phases into which a project evolves to complete each of the agreed upon deliverables. Hence, one of the most commonly-used WBS’s is breaking down the project into phases, deliverables, sub-deliverables, and Work Packages that collectively constitutes the overall scope of the project.

If WBS represents the lifecycle, how should PM processes be represented as part of the project effort? Project Management is actually a phase in the WBS that has its own deliverables, sub-deliverables, and Work Packages. Taking a software development project as an example, the WBS shown in figure (1) is what is expected to represent the lifecycle and scope of the project (WBS in its initial structure for illustration purposes). 

Figure (1)-Software Development WBS

As shown in figure (1) the Analysis phase of the project consists of two deliverables: Glossary, and Requirements Specifications. The SRS deliverable consists of three sub-deliverables: Use Cases, Supplementary Specifications, and Reporting Requirements. The sub-deliverables can be broken down further into Work Packages (components that can be estimated for required time, resources, and cost). Use Cases, for instance, can be broken down into more specific use cases discussed with customer or user of the system under development.

Although WBS is progressively elaborated (built in increments as project progresses) a PM should make sure her WBS is complete and constitutes 100% of the agreed scope. All phases should make up the 100% completeness of the project. And all child deliverables under each phase should make up 100% of the parent phase, and so on. This is one way to ensure a WBS, so scope, completeness.

After a WBS is structured correctly, a project schedule can be established. From each deliverable or Work Package in the WBS PM with her team members can list the required activities to build each component. Time, resources, and cost are then allocated to each activity of the component after which a project schedule (e.g. MS Project Plan) is generated and schedule baseline is then set.

The indispensable Quality couple

Most companies realize the ever-existing conflict between Quality Control and Production functions, but unfortunately, very few have realized or thought of the function that bridges the gap between them, namely the Quality Assurance.

It was more than 10 years ago when I was wandering in a steel manufacturing plant and saw a pile of steel rafters laid down in an area marked “Defects”. There, I met an exhausted, yet happy, man taking measurements of rafters and record them in a ‘checklist’. He was the QC man. “I’m ensuring rafters are produced according to quality standards,” he said. “20-25% is our daily defects.” “Has this percentage ever decreased?” I asked. “Nope, it’s the same for years, but we always take corrective actions to repair defects to assure quality.” QC man replied with a puzzled look. “You’re not assuring quality, nor do you control it. You merely inspect products and add more cost to it.” I replied irritatingly. I knew it might have been a tough answer by me but the misunderstanding of the QA/QC balance is tougher!

Quality Assurance (QA) and Quality Control (QC) exist in every aspect of our lives, not only in business. If I exercise and eat healthy food, I’m assuring good health in my body and I will not worry much when I do my check up at year end. If I follow controls outlined in a procedure to gather input data, I will not spend hours checking my analysis results in reports raised to top management.

In the realm of Project Management, to Assure Quality you need to follow specific activities to make sure that project processes will result in the required deliverables. We don’t wait to inspect deliverables during Monitoring & Controlling phase; we rather ought to build quality up front. And this should be done throughout the project life cycle. However, QA alone is not enough to ensure quality deliverables and QC tools should be employed during Controlling phase to determine whether project results comply with the set quality standards of the project.

QA is a process-related function. It is done during performing work to improve chances of getting quality output before it is resulted. Quality Audits are independent reviews to ensure that project activities are performed according to policies and procedures that have already been set in the Quality Plans. Another tool to assure quality in project activities is the Process Analysis which is concerned with identifying needed improvement in the current project processes to produce quality deliverables.

On the other hand, QC is a product-related function which inspects the end deliverable to determine if it meets the quality standards. This is usually done during the Monitoring & Controlling phase of the project life cycle.

Having said that, QA and QC do not stop at what I’ve mentioned above; they continually operate to correct and to prevent failures and to reduce Cost of Quality (COQ). Many tools and techniques can be used to do this job such as Fish-Bone (Ishikawa) diagram, Control Charts, Histograms, Pareto Chart, Run Chart, Scatter Diagram, and Statistical Sampling. The theme behind these tools is to learn the cause of problem, correct it, and prevent it from happening again. Hence, reducing project cost.

“Shearing machine was not calibrated for ages!” the QC man whispered to me the next day. “Please, let’s sit today and document a Standard Operating Procedure for machines calibration.” I whispered to him. We compiled the calibration procedure and published it immediately. Consequently, defects dropped to 12% the following couple weeks.

The Tightrope Walker in Your Organization

tightrope-walkerMost of us enjoy watching a tightrope walker in circuses trying to walk along a rope to reach to the other end without falling down. Skillfully, he uses a balancing pole to make it to the other end while being secured with a safety net. Sometimes this walker takes your breath away when he slips off the rope and falls in the safety net, yet, you know that he is not hurt. When it comes to real life and you look around you will see a real tightrope walker in your organization whose slip may cause a disaster not only to him but also to the entire organization. Guess who! He is the Project Manager (PM).

All what a PM does is trying to reach from one end of a project (Initiating), to the other end (Closing) safely by keeping all of the project’s competing demands balanced. What is funny about this, and at the same time challenging, is that most of project stakeholders (SH) know what competing demands are, and they are even skilled at stretching them. All of them know that a PM has to deliver within scope, time, budget, quality, and available resources. However, none of these SH knows what ‘Balancing Pole’ is to use to keep these demands balanced. Even if they know it, they don’t know how to use it. Here comes the role of our Tightrope Walker; the PM.

I will touch on three key management areas a PM uses as Balancing Pole to maintain the balance in his project’s competing demands which are Integration, Communication, and Conflict management areas.

A PM needs to keep his project balanced by keeping it integrated both on technical side and human side. For example, maintaining an effective Change Management procedure enables the project manager to incorporate any requested changes into all project baselines; i.e. if an implemented change affects scope, it has to be reflected to cost and time as applicable. The feedback loop of continuous update to project management plan as he executes the project is another way of integration that maintains a balanced project throughout lifecycle.

Regarding human integration I emphasize the skill of integrating the project team members together to work as one cohesive unit towards one objective. Just like football team players whose coach harmonizes their performance to score goals. For example, building the Work Breakdown Structure (WBS) is an activity that helps the PM integrate his team members as it involves collaborative effort from all of them.

It is said that 80% of projects failure is due to poor communications. A successful PM is the one who continuously maintains links with all stakeholders to satisfy their information needs and to best manage their expectations about the project. Whether it is through effective meetings, presentations, emailing, or conference calling the PM is kept updated with any requested changes that SH need at the right time. Besides, by building an open communications environment a positive constructive atmosphere amongst team members is created where ideas are shared and team work is fostered. All that gives a heavy mass to PM to keep him balanced in the project journey.

Conflict management is directly related to communications skills. A proficient communicator is most probably an effective conflict-solver. It is worth mentioning that mastering the strategies of conflict resolution is a key to maintain harmonized performance in project team. Unhealthy conflicts are disruptive and detrimental to the project. On the other hand, a PM should realize that conflict is sometimes healthy and needed in projects; a project with no conflicts is actually an ‘unbalanced project’.

At the end of the day it is the PM’s challenge to keep the project balanced. The more skillfully a PM performs ‘tightrope walking’, the more he ‘entertains’ his stakeholders and the more likely he makes it to the other end of the rope without falling.

The 80/20 Project Manager

Professionals’ characters are made up of two components; the Technical Skills and the Human/Managerial Skills. These two categories of skills are competing against each other. If someone becomes more of a technical style professional, his managerial style will be affected, I would say, adversely. So, what do we think is the right composite of a successful project manager? Are employers recognizing this important composite character in any Project Manager they seek to employ? And how a technical person can be converted into a good Project Manager?

“A Technical Expert Wanted” is what some job postings should be titled nowadays rather than “A Project Manager Wanted” especially for employers who do not appreciate the 80/20 skill composite of a Project Manager. To me, it is disappointing to see a posting seeking a project manager while more than 90% of the job requirements are in technical specialties and only 10% are of human or managerial skills! If the first and foremost job requirement is someone who has 15+ years of experience in a technical specialty, then you need a technical expert or a SME who will be inundated with solving and dealing with technical issues during the project lifecycle. Well, then who is going to manage your project; manage your team, manage your stakeholders’ expectations, and balance your project’s competing demands of scope, time, cost, quality, HR, and risks? Who is going to keep integrity and harmony amongst team members to achieve project goals? Who is going to communicate and report on performance? The answer is “Mr. Project Manager” but not the one you are seeking in your posting. Both PM and SME would never exist in one person. So, if I were one of these employers, I would seek two posts; “A Technical Expert” and “A Project Manager”, but I would never jeopardize the success of my project by asking for a Project Manager to play both roles.

Best practices show that a successful project manager has to have his skills composed of at least 80% human and managerial skills and at most 20% technical skills. I believe that bringing a project to success is a collaborative effort in which all stakeholders are involved. If stakeholders do not find the Leader to inspire and integrate them to achieve the project’s vision, the project would fail. This challenge for a PM is not achieved by sitting for hours and hours in a closed room solving a technical problem in the project, it rather is achieved by living the project with team members. Hence, communications is the paramount skill a PM should possess.

Having said that, a technical person can be a good project manager by acquiring the right managerial skills required to lead his project team. On the other hand, he should be kept away from being involved in technical issues, and even not leaving a room for him to be attracted to technical issues. Some good employers assign each project manager up to 4 projects at a time rather than having him manage one project and doing other technical tasks. By this they help him build up his human and managerial skills that are precious to their projects success.

Stakeholders and the Cost of Change

Any individual or organization whose interests may be affected positively or negatively by the completion of a project is called a Stakeholder (SH). He could be a positive stakeholder such as the customer, the sponsor, the supplier, the project manager himself, and he could be a negative one such as the competitor. But how the involvement of these people affects the success of a project, and how they influence the cost baseline as the project progresses.

When I think of stakeholders in any project I immediately link it to the GIGO phrase (Garbage In, Garbage Out). A project is initiated, planned, executed, and closed around the requirements stated, and implied, by project stakeholders. In other words, the project’s success is heavily dependent on stakeholder’s input and involvement. If their input is weak, little, rare, or late in the project lifecycle the end product or service would be a costly ‘Garbage’ gathering dust on the shelf.

SH influence in a project diminishes over time due to the increasing cost spent as the project progresses. Hence, it becomes more difficult to introduce changes as we spend more in the project. So, the Project Manager (PM) should involve SH as early as possible when the cost spent is low.

The earlier and more intensive SH involvement in a project is, the more likely the project successfully finishes within the Triple Constraints (Scope, Time, and Cost) achieving a high quality end deliverable. SH Analysis is a vital tool to be used by the project manager (PM) throughout the project lifecycle, especially in the planning phase, to guarantee meeting his SH needs. With this tool the PM identifies SH influence, interests, and needs. Then he prioritizes and quantifies the needs and then translates them into project requirements stated in the Scope Statement. This is a repetitive activity that should be done throughout the project and according to the Change Management Plan so as to prevent Scope Creep.

Not only does SH Analysis prevent deviation from project objectives, but also it minimizes the risk of cost overrun. If a key SH’s need was not detected early during planning, it may cause rework as well as going behind schedule. It becomes much difficult and costly to rework some activities during Executing due to a missing key SH requirement. Because of that it is a good, and may be a must-do, practice to spend considerable time in planning processes, especially the Scope Management ones to compile a comprehensive list of SH’s needs.

Another important practice to involve SH and to mitigate cost overrun risk is the use of Phase Exit Reviews or Gates in addition to end-of-phase verification process. At the end of each phase in the lifecycle the PM should validate deliverables of the phase against scope baseline and that the requirements to proceed to the next phase have been met. In addition, the PM should seek documented acceptance from key SH on deliverables at the end of each phase through what is known as Scope Verification process.

I would say that sticking to the SH Analysis tool and to Scope Verification process would minimize probability and impact of cost overrun risk and of having a useless end product or service.

Progressive Elaboration

A project is defined as a temporary endeavor undertaken to create a unique product, service, or result. This definition explicitly states two of three characteristics of a project-Temporary (which means it has definitive start and end dates), and Unique (in the end product or service delivered out of the project). However, this definition implies a third important characteristic of a project which is Progressive Elaboration.

If you are reading a book discussing a topic that is new to you, you would start with the preface that gives you an overview about the book’s subject. This high-level synopsis about the book would be clearer to you in more details as you read more through the sequential chapters. At the end, you would find yourself having comprehensive and detailed knowledge elaborated as you progressed in your reading.

Managing a project resembles reading a book in the way knowledge and details are being built up as the project goes on. It means that a project is developing in steps and is continuing by increments. As more details become available as you progress in a project, you update your high-level initial plan and come up with more accurate estimates. For example, if you have a 2-phase project lifecycle (Concept and Design) your first iteration in planning will be some high-level or fairly detailed Concept phase with very few details on the Design phase. As the project progresses you will get more details about requirements that fit into the Concept phase and adds more details to the Design phase, and so on.

Progressive Elaboration characteristic in a project leads to what is called Iterative Processes. These processes result in outputs that feed into other previous processes to update the plan. For instance, when you create the Work Breakdown Structure in the Create WBS process you might end up with some necessary updates to the previously built Scope Statement (during the Scope Definition process). Hence, this output/input update phenomenon from one process to another builds up the progressive elaboration characteristic of projects.

As we can see this feature makes managing projects a flexible and an integrated endeavor. Project management processes work together in harmony to constitute one integrated vehicle that would lead project team to achieving project deliverables within set constraints. However, progressive elaboration should be used with care and according to the Change Management Plan so as to prevent what is known as “Scope Creep” that I will discuss in my coming blogs.

Spirit of PMI

In an earlier blog I discussed the values of being a PMP Project Manager, and in this blog I will discuss the frame of mind all Project Management Professionals (PMPs) have in common which makes them distinguished in managing projects.

Spirit of PMI (the Project Management Institute) is the frame of mind or the mindset or the paradigm through which PMPs manage projects. It is the hat that PMI requires PMPs to wear when managing their projects in order to successfully achieve project objectives. If you read the PMBOK Guide you can feel this spirit throughout the five Process Groups-Initiating, Planning, Executing, Monitoring & Controlling, and Closing.

As a Project Manager (PM) to be a decision-maker is an essential part of this spirit, for instance. Although a PM should share ideas and get input from key stakeholders in arriving to the best decision to take, he should not wait for others to make decisions on how to proceed with the project, and he is the one ultimately responsible for any decision taken in the project.

In another instance, you can feel the spirit of PMI in Scope Management. Creating the WBS (Work Breakdown Structure) is an essential process that must be performed to manage the scope of project. WBS is one of the tools that make Project Management distinguished from all other industries or areas of expertise. Another piece of this spirit is the emphasis on using historical data as input to any new project. As I discussed in my previous blog about Lessons Learned, historical data could be the lessons learned from previous projects that PMs can use to manage their new projects efficiently and effectively.

Stakeholders and Stakeholder Analysis are important aspects in managing projects. PMI focuses on stakeholders’ early involvement in any project. Stakeholders’ needs must be considered and prioritized then translated into requirements. The earlier stakeholders are involved, the more likely the project closes successfully within constraints.

Prevention rather than detection is an important part of PMI spirit. A PM must be proactive. He should analyze and anticipate problems before they occur then take the proper preventive actions ahead of time. He should not wait until problems or risks become issues that jeopardize his project success.

What I mentioned above along with many other topics in the PMBOK Guide compile the Spirit of PMI that gets PMPs together despite the different geographies, languages, backgrounds, and attitudes.