“PROJECT MANAGEMENT: Software/IT Projects (Course)” is a course
which contains numerous beginner, intermediate and advanced concepts from the field of software project management. Besides the management of software projects, the course is also useful for the management of other IT projects, as the project management fundamentals are similar. Whether you are a project manager now, or aspire to be one later on, the course will help you to add some of the best project management terms, concepts and principles to the core of your professional skill set. These concepts and principles will then be ready for use in the professional world, whenever they are needed. With the insights, ideas, principles and concepts presented, you will be able to manage a professional software project or many other types of IT projects. If you are a beginner in this area, the course will help you to understand the kinds of things that need to be thought about to be effective in the role. The knowledge presented will help you to become either a better contributor to a software production team or a better manager of an IT team. The information will help prepare you to progress to the next level in your career. If you are a professional already in this field, the course will allow for refinement of process and continual professional development through the presentation of interesting insights and perspectives.
The course emphasizes the project management approach and all steps required to develop a software product, service or information system. Many project management areas of knowledge and software engineering principles are discussed. The number of terms and concepts is high, and as such, the course is divided up into fourteen sections. We will discuss: Definitions, Initiation, Planning, Requirements, Scope, WBS, Schedule, Estimation, Communications, Procurement, Cost, Risks, Execution, Testing, Quality, Control and Closing. Within each section, there will be at least one lecture on the relevant topic, but most sections will feature at least a few lectures. This course demystifies a broad range of knowledge areas within project management, and organizes the areas ideas into small, clear and simplified modules of discussion.
Without at least a basic understanding in this area, it will be difficult to be selected as a project lead or project manager. It may even be difficult to work under a project manager, without understanding their process. The course will assist project contributors to understand the project process. The language used in this course will assist aspiring project managers to be selected for the role. It will also assist practicing project managers to use the specialized terminology required and to refine the practice.
Course Curriculum
1 Definitions, Initiation and Planning – Introduction
INTRODUCTION – According to Wikipedia, “Software project management is the art and science of planning and leading software projects. It is a sub-discipline of project management in which software projects are planned, implemented, monitored, and controlled.” In this course, I provide software project management examples. However, the course is also useful for aspiring Information Technology project managers, as the project management fundamentals are similar. Sometimes, people confuse Information Technology project management and Software Project Management. The term Information Technology project management is more comprehensive than Software Project Management. IT project management includes many types of projects, including; network upgrades, cloud computing rollouts, virtualization rollouts, business analytics and data management, hardware installations, and also overseeing projects for software development.
One of the reasons I decided to create this course has to do with research I came across on IT/software project management. According to research by McKinsey & Company in collaboration with the University of Oxford, the research suggests that half of all large IT projects massively blow their budgets. On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted. More specifically, for the “software project type”, 66% of projects were over budget, 33% of projects were in a schedule overrun, and 17% delivered less value than predicted. Now this is a terrible situation to be in, assigned with the responsibility of leading something were the odds are stacked against you. This is the main reason I decided to create this course. I wanted to help provide a reliable, quick, and to the point guide that aspiring or practicing project managers can refer to, to reinforce their practice in this field. Because software projects run the highest risk of cost and schedule over run, knowing the software project management process inside and out can help prepare and protect you while in this role.
The companies that initiate and execute these projects expect a return on their investments. After all, software projects take a considerable amount of effort, time, money and resources, and expecting nothing in return would be ridiculous. Some people believe that simply knowing project management is enough to lead a software project. However, even though many project processes are similar, the engineering principles of building an application is different than constructing a bridge. In this course, I combine some of my knowledge in software engineering and project management, with official body of knowledge of the project process so as to create a great guide for managing software and IT projects.
There is also one more thing to consider. Sometimes, at work, individuals are placed into positions that they are not yet ready or trained for. This is very problematic, especially, when a person with a technical background is suddenly thrust into a position of management in their IT department. Now, the promoted individual is expected to know a lot of things about a lot of different topics, and they are also not prepared or given any training. To prepare for success, this course is designed with the most important terminology of IT/software project management. This course is useful for both new IT/Software Project Managers and future managers as well.
SOFTWARE PROJECT MANAGEMENT
A project is an endeavour that aims to produce a result, such as a product or service. It has a date on which it will start, and it has a day on which it will end. “Software Project Management” is the management of a special type of project dealing with building software. To be able to manage software projects, the project manager needs an insight and knowledge into various aspects of the development lifecycle. The project manager needs to know about the requirements gathering, finding staff, estimating costs, creating schedules, monitoring work, software implementation, software testing and other concepts. These tasks and concepts, which a project manager must know, are varied and diverse. The project manager will need to source knowledge and insight from different areas to be successful. This course aims to package project management knowledge and software insight into a condensed presentation.
There are a few terms to be familiar with, as they will be used throughout the course.
Project Manager – The project manager managers the project and must deliver the project within budget, within quality requirements, and within time constraints.
Project Sponsor – The project sponsor is an executive. The sponsor performs business functions such as convincing stakeholders to maintain their support, coaching the PM, and other tasks. The sponsor also assigns resources or money to the project.
Stakeholders – Stakeholders are groups, organizations or individuals who have an interest in how the project turns out. Examples include: project sponsor, project team, other managers, customers, and users.
ORGANIZATIONAL STRUCTURE
While managing a project, a project manager will run into different types of difficulties. It is good to be aware that some of these difficulties may arise simply due to the nature of the organizational structure that one works under. The organizational structure has an impact on the project management process, and therefore, it has an impact on the project manager. The project manager needs to be aware that their level of authority is tied in with the type of organizational structure. Let’s review three types of organizational structures.
Functional Structure – Functionally structured organizations are arranged along departments such as: manufacturing, sales, customer service or technical. Each department has it’s own management.
Project Structure – Project structured organizations supports multiple projects at the same time. Each project is it’s own unit, each of which contain their own technical, operational, marketing, quality, finance, human resource, legal and administrative support functions. The project manager has a lot of authority under this structure.
Matrix Structure – In the matrix structure, team members can be selected from anywhere within the organization. Additionally, team members have to report to two supervisors, the project manager and their functional manager.
PROJECT LIFE CYCLE
As a project progresses, it must move through different phases. Whether it’s a project in construction, healthcare or technology, you will find that they are all similar in that the same project management processes move the projects the phases. Most projects are segmented along phases. The phases of a project are referred to as the project life cycle. The project life cycle is broken down into process groups, such as: Initiating, Planning, Executing, Monitoring and Controlling, and Closing. The process groups:
Initiating – Initiating refers to the start of the project. It includes: definition of scope, evaluation of the project idea, and assessment of feasibility.
Planning – Planning refers to the planning for each phase of the project and the entire project.
Executing – This work creates the product or service that the stakeholders want.
Monitoring and Controlling – Monitoring and Controlling processes refer to actions to oversee the progress of the project. It refers to actions to identify and correct for variances from the initial plan.
Closing – As part of Closing, the project manager must verify that the deliverables were completed to specification.
SOFTWARE PROJECT INITIATION
Projects usually begin with a project request. This type of request can be as simple as an informal meet and greet, where a boss quickly discusses a project idea. Or it can be a formal request that requires written documentation. Whether the initiation of the project is formal or informal, they both require that the project manager to conduct research and provide a detailed response. The project manager would need to analyze the request and then proceed to collect relevant information that will help the organization to decide on whether to pursue the project. So how does a project manager go about collecting the right information? To know what questions to ask, the PM will need to understand why the project exists and what the reasons for the project are. With this information in mind, the right information can be asked.
3 Definitions, Initiation and Planning – Business Case
BUSINESS CASE
The “business case” can most easily be remembered as the documentation, which the project manager produces, to outline the “reasons for a project”. Most companies launch projects, for a reason, or to meet a particular business need. The companies have needs, and the projects are a way to meet those needs. The project manager must be aware of company needs and must document business reasons in a “business case”. Another way to understand it is to think about what information do the leaders of the companies require to make a decision on whether a project should be funded. That information, to be placed in the business case, is the information that will assist the organization in the evaluation of whether or not the project will be beneficial and a good investment for the organization. The business case will need to include at least four things; benefits, risk, cost, and planned results.
4 Definitions, Initiation and Planning – Planning The Project
PLANNING THE PROJECT
By planning a project, the project manager is generating necessary documentation, or a “project plan”. The documentation will reveal what it is the project manager wants to achieve and what methods will be employed. For tasks to be achieved, the positions of those responsible for the work will need to be defined. In addition, the resources that will need to be made available, the work breakdown structure and the management plans will need to be defined. Further, details on how the project will be executed and how it will be controlled and how it will be closed will need to be defined.
5 Definitions, Initiation and Planning – Project Charter
PROJECT CHARTER (CREATION)
After defining the business needs, the project charter can be created. The project charter acts as a bridge between initiation and planning. The project charter is identification and an authorization document. The charter identifies: the pm, the project sponsor, and the team leaders. Further, once the project sponsor signs the charter, and therefore authorizes it, this provides the authority for the PM to start the project. The information on the charter can be provided to the stakeholders, and this will serve as a reminder of the project manager’s authority.
6 Requirements – Win Over The Programmers And The Designers
WIN OVER THE PROGRAMMERS AND DESIGNERS
Some organizations have a software requirements process in place, and some do not. In the organizations that have a requirements process in place, it is likely that the programmers and the designers are used to working with requirements. However, in the organizations that do not have such a requirements process in place, implementing one can be tricky. In organizations without a requirements process, the designers and programmers may not be used to working with requirements. If these organizations then proceed to adopt the use of requirements, initially it can feel restrictive to the creative process. If the project manager then makes workers adhere to requirements, the workers may have a hard time adjusting to the new processes and may even complain to senior management. Often times, senior management has no clue about programming processes and may listen to the complaints of the workers. Their complaints could derail any effort to integrate a requirements process into the organization.
In order to convert an organization which does not use requirements to one that does, the project manager needs to convert the programmers and the designers which are resistant to the requirements process. A good way to do this is to educate the programmers and designers on how it will enhance the software creation process and help build better software. In regards to helping convert a programmer to requirements, it is important to show them the benefits that requirements can bring to help control the change process. If a programmer spends weeks developing software, but then at the last minute changes are requested, it is likely then that the programmer will have to redo a lot of work. No programmer would like this and would probably do just about anything to avoid this situation. Well it turns out that requirements can be used to help reduce change. The requirements can help control changes, and that will help the programmer to build better code, rather than having to rebuild the code over and over. In regards to a designer who is resistant to the requirements process, they may be resistant due to the fact that they may feel that they will not have the flexibility to design software. For this type of situation, it is important to show that the requirements are only limited to the behaviour of the software, and do not affect the design. By guaranteeing the ability of the designer to be creative and the flexibility to design, it should be easy to convert a designer to a requirements process.
7 Requirements – Requirements Gathering
REQUIREMENTS GATHERING
Requirements gathering is a process by which a project manager or the requirements analyst interviews the experts, users and stakeholders; and then using the data gained from those interviews is able to define the project requirements. Some project managers are lucky and have an analyst who can do this, but other project managers must do this themselves.
Requirements are an important part of software development. Without requirements, the process would not be structured enough, and could even lead to chaotic and undisciplined code. Writing code on the fly, rather than by following a reference guide is in fact what many programmers like. Many programmers would like to program without requirements. Programming without requirements can be less restricting, and this type of freedom can be intellectually liberating. Being free to solve the problem in any way in which one desires and without the adherence to strict guidelines can be enjoyable. In fact, this is how many programmers learn their craft. They write software for themselves, for their own internal requirements specification. However, in the professional world, programmers need to be able to write software for other people. When programming for someone else, the programmer will not know exactly what it is that another person wants. This is where requirements specifications come in. As such, the behaviour of the software to be programmed must be documented before the software is to be developed. The process of developing the description of software behaviour is known as “software requirements engineering”.
REQUIREMENTS
The requirements document needs to accomplish at least two things. First, it needs to define what it is that the project will make. And second, it needs to connect the needs of the business to the product or service, which will be created. To accomplish this, the project manager will need to interview the stakeholders, the project customer, and the project team. From these interviews, requirements along the functional, technical and business domains can be generated. In addition, the requirements document is a central document from which other project documents will be generated. It must be done right. To show the agreement that has taken place between the customer and the project team, the project manager and the customer should sign off on the document.
One more thing to be familiar with: When we talk about documenting requirements in software development, the term “software requirements specification” or SRS is often used.
The SRS will contain a description of the behaviour of the software. The document will contain a set of “use cases”. The use cases will describe the interactions that users will have with the software. Also in the document, will be included the functional requirements, which will describe technicalities such as information processing, data manipulation and other calculations. Lastly, non-functional requirements will also be included, which refers to things such as quality and performance. Again, from the requirements, it will be possible to generate other necessary documents such as the design documents, coding, and testing.
9 Scope – Project Scope Statement
PROJECT SCOPE STATEMENT
After the business case and requirements have been documented, the PM can work on the scope. The scope states what it is that will be made throughout the project. It defines the deliverables that will be created. In short, the scope statement is an agreement between the customer and the project team that defines what will be created throughout the project. If at the completion of a project, the customer complains that a feature they wanted was not included in the project, then the scope can be used as evidence to prove that the feature being discussed was never part of the original agreement. The scope sounds very similar to requirements specifications, but it is much more. In fact, the scope is an elaboration of the requirements specification. The scope describes things not covered in the requirements such as back end programming, software interfaces, type of technologies used and other complex details.
SCOPE CREEP – Projects often fail when leadership is not careful in monitoring and controlling the project against change requests. A lack of careful change control policy will place any project at a high risk of failure. Change requests can come from all over the place, including; team members, senior managers, users, stakeholders and other sources. Many times, when someone requests a change, it often has the appearance that it will have a minimal impact on the project. It often appears to be a request for a very small change. In reality, what may seem small may end up being very difficult to implement. This problem, of changes requesting a modification of the original plan, is referred to as “scope creep”. Changes that are requested usually require time and money to be implemented. However, the change requests don’t often come with additional time or money. As a result, resources that were originally assigned to ensure the success of the project will then be re-assigned to handle the changes. This can lead to project failure.
In an organization, the individuals who definitely understand the impact of scope creep are the programmers. When they have to implement changes, they have to re-write and patch code that they’ve already written. Making changes to code after a design has been implemented may ruin the elegance of the original design. Programmers would much rather be provided with a good design to begin with, one that doesn’t need to be changed later on.
SCOPE MANAGEMENT PLAN
The scope management plan is a plan where information relating to customer verification of the scope, monitoring and controlling of the scope, and definition of the scope is included. As part of this plan, a project scope statement, a WBS, and a WBS dictionary will need to be created.
SCOPE DOCUMENT
There are several steps through which the scope document must go through before a project can go to the planning phase. First, the scope document must be written. Second, the team should review the scope document. Third, the document should be presented to the stakeholders. Doing these steps is critical, as it helps the project manager to discover any inconsistencies or missing information within the document. The project manager should also attach a sign off sheet for the project sponsor and the main stakeholders to sign off on. The sign off approves the scope document and allows the project to go onto the planning phase.
11 WBS & Schedule – Work Breakdown Structure
WORK BREAKDOWN STRUCTURE
After the project scope statement is approved, the project can be planned. The project scope statement is used to create the Work Breakdown Structure. A Work Breakdown Structure is a graphical view of what the project will create. It is a breakdown of the project scope statement into component parts. The scope statement can be complex and large, and in order to understand it, it is useful to decompose it into manageable components. Another way to understand the WBS is through the view of levels. The top most level is the project itself. At the next level below, there are the major deliverables, project phases or subprojects. Then there are more sub levels where the work is decomposed into smaller and smaller units. The lowest level is called the work package level. The work package level is used for creating estimates for time, cost, resources, and is used for scheduling. Overall, it is useful to know that the Work Breakdown Structure (WBS) helps to create a better project plan, and connects the scope statement to the schedule and to the budget.
To move the project forward, the Work Breakdown Structure will need to be presented for approval. First, it will need to be presented to the project sponsor. The project manager will have to go over the Work Breakdown Structure, as well as the WBS dictionary, and answer any questions the project sponsor may have. After the project sponsor approves the WBS, it will then have to be shown to the key project stakeholders. After the WBS is completed, the next planning document you’ll develop is the project schedule.
PROJECT SCHEDULE
The methods and techniques of project scheduling is not a focus of this course. However, the basics of building an accurate schedule will be discussed. To start off with, what is a schedule? A schedule is simply a calendar which links tasks that need to be accomplished to the available human resources. To build an accurate schedule, the project manager will need three pieces of data. First, the PM will need a Work Breakdown Structure. Second, the PM will need to have an understanding of how much effort the tasks take. Third, the PM will need to know when the different resources are available. This information will allow the PM to build an accurate schedule.
For many managers, offering an accurate estimate in not a comfortable thing. Many project managers are not comfortable with providing exact time estimates. There are many possible reasons for this. Consider that projects are complex endeavours that require many complex interactions in the real world, and this means that many unexpected events and challenges can appear along the way. Unexpected issues or events or challenges can compromise the project timeline. An unexpected issue could be something as simple as one of the contractors upon which the project is depending on delays in providing the required work. This issue then delays the entire project. In an attempt to create a buffer or built in margin of safety in the schedule, the project managers pad their estimates with a bit of extra time. There could be other reasons why a PM would pad an estimate. They may have personally experienced some failed projects in the past, and out of a fear or general risk aversion feeling, may pad the estimate excessively. Or perhaps the project manager is very experienced and senses that the customer is very conservative with the time to be spent on the project. In this scenario, the project manager may pad the estimate, and therefore leave more negotiating room in regards to cutting time from the project. As you can see, there are many reasons why PM’s are not comfortable with giving exact time estimates.
ESTIMATING
PROJECT ESTIMATION TECHNIQUES
One of the things which the project manager needs to know, is how long the different project tasks take to complete. If the task completion time is not known, and it usually isn’t, it will need to be estimated. The estimate allows the project manager to schedule the project accordingly, determine a project completion time, and to create the budget. Getting it right is important. There are several techniques, which the project manager can use, to estimate.
Guesstimating – Project managers without much experience will sometimes use the “guesstimating” technique. However, these estimates are not based on evidence, and as such, cannot be trusted to be accurate.
Time Boxing – Time Boxing is about focusing a team’s effort on an important task. Time boxing allocates a “box of time” or “window of time” for a task. If they fail to meet the requirement by the deadline, the work on the application stops. This increases the pressure on the team, and often team members end up working overtime to meet the requirement.
Top-Down Estimating – Top-down estimating refers to the estimate provided by upper management to the project team, which directs the team as to how long the project should take or how much it should cost. Often times, these estimates are too demanding, too optimistic and not realistic enough. In this type of system, the project manager simply must work with what is available, and take the amount of money or the amount of time provided, and break these down into percentage allocations to the various phases of the project.
Bottom-Up Estimating – Bottom-Up Estimating requires that the project manager break up the project into smaller components. These smaller components are easier to estimate as they represent a lower complexity calculation than it would take to estimate the whole project in one go. The individual components are estimated for time and cost, and this data is used to create the project schedule and budget.
Delphi Technique – Under the Delphi Technique, a group of subject specific experts are asked to individually estimate how long particular project phases or tasks will take. They come up with estimates, some of which group together and some do not. If the estimates group together, the estimates are averaged together, and the result is an accurate estimate. If the estimates do not group together, the estimates and the rationale for the estimates are given back to the group. The group is then asked to use the new information re-estimate. Several iterations of this process can occur and eventually the group will come to a consensus.
13 Estimation – Distrust About Estimates
DISTRUST ABOUT ESTIMATES
When it comes to the idea of providing an estimate about the work to be done for a supervisor, there can be a bit of mistrust between the workers and supervisors. This concept applies to many disciplines, including the software development field. In the software field, leaders often need to ask the programmers for an estimate on the work. Many leaders are non-technical people and do not have an idea of how long a certain portion of programming work will take. Many leaders do not trust the programmers and make the assumption that the programmers must be padding their estimate with extra time. As such, the leaders proceed to cut the available time to do the work anywhere from 10% to 50%. They reason that this will “keep the programmers efficient” and will “avoid any waste”. Programmers have a sense that potentially their estimate could be cut down and that they then will be forced into a hard working speed frenzy where they will need to rush the project to completion. Sensing that this could happen, the programmers do in fact add padding into their time estimates. The level of mistrust in organizations can vary from slight to severe, and can compromise the project. Accurate time estimates and the right level of trust are critical to a smooth running project.
One thing, which project managers can do to resolve the mistrust in estimates, is to educate the relevant parties on the estimation process. For example, a project manager can have another manager or a stakeholder attend an estimation session. In this session, the systematic ways in which a team arrives at an estimate can be observed and understood. An understanding of the relationship between programming work and time required to do the work will gradually develop. With everyone better able to judge the time required for different modules of work and with the view gained from the programmer’s perspective, an increase in trust should occur about the estimate and the process used to achieve that estimate.
14 Estimation – Estimation Politics
ESTIMATION POLITICS
When a project manager estimates the length of time for project completion and then proposes the time to the customer, it can be a little bit political. Under the scenario that the project manager tries to sell a very small time frame to the customer, the customer would like this estimate, however the short time frame increases the risk of project failure. Under the scenario that the project manager pads the time estimate with extra time, and proposes a long time frame, then there is a risk that the customer will not accept the estimate. Luckily, with this scenario the project manager is able to cut the padding and make a second proposal for a shorter time frame to try to rescue the proposal. And lastly, there are some project managers that wish to look quick and efficient and may try to sell the project as taking a certain amount of time that is longer than they believe they can complete the project in. Naturally, producing a project in a shorter time frame than the original estimate would make them as project managers and their team look good.
15 Communications – Communications Plan
COMMUNICATIONS PLAN
The job of the project manager entails a lot of communication. In fact, project managers can sometimes spend up to 80% of their time communicating. The project manager needs to communicate with members of their own organization, members of other organizations, clients, the team, the public and others. Without a systematic and planned approach towards the communication process, the involved and demanding communication requirements would overwhelm the project managers. A communications management plan is a plan that defines when communications should occur. A communications schedule can be created which can outline specific and dedicated sessions of when certain communications should occur.
PROCUREMENT MANAGEMENT
Procurement management is a term that refers to the process of managing the acquisition of products and services from other external organizations. Projects often require products and services that are not available within the organization running the project. And even if the organization has the capacity to complete the project with internal resources, it is often more advantageous to split the project into sub-projects and subcontract certain portions to outside contractors. In short, it is often the case that something needs to be procured. Here are some common terms to be familiar with.
Statement Of Work
The Statement Of Work is a list of the services and products, which the project manager wants to procure. This list allows the vendors to know what it is that is needed.
Vendor Solicitation – Vendor Solicitation is the process of gathering responses from vendors.
Vendor Selection – Sometimes the organization has procurement department, which can handle vendor selection. At other times, in the absence of such a department, the project manager must do this. Good vendors have experience, understand the project, have the necessary technical capacities and have references. These are the things to look for.
COST ESTIMATES
Generally, the project manager should strive to provide a realistic cost estimate of the project costs. This can be a challenge for various reasons. Consider the number of unknowns that exist or can crop up throughout the execution of a project. A project could be very large, or very long, or it could be complex. The project may need to utilize new processes, techniques and technologies. These types of factors can make projects hard to estimate. And even if it is possible to estimate with reasonable accuracy, the project manager may have reasons not to provide an accurate estimate. For one, what if the project manager is overly optimistic and provides an unrealistically short estimate. This may allow the project to be approved, but it also means that the project is likely to fail. On the other hand, what if the project manager is concerned that unexpected factors could crop up throughout the execution of the project, and proceeds to provide and overly lengthy and inflated time estimate. Under this scenario, the project will be perceived to be too expensive. This places the project in jeopardy of cancellation. Consequently, the best situation is to provide the most reliable and accurate estimate possible.
COST VARIANCES
When one thinks about the cost of a project, it is not immediately obvious to think about the idea of variances. Variances represent the difference between the cost that is planned for a project and the actual cost that the project will incur as it is executed. Often times, as the project is executed, the actual cost ends up exceeding the planned cost, and this difference occurs as variances are created. Think about an example where a variance occurs due to a “resource change”. Imagine the planned project cost is calculated based on the assumption that only two junior programmers will work to develop the software. Now imagine the scenario that they run into the situation where they cannot solve a critical programming problem and an expert senior programmer needs to be recruited to solve the puzzle. In this instance, the actual cost will be higher than the planned cost. Or perhaps one of the junior programmers quits, and hiring another junior programmer replacement can only be done at a higher wage. These kinds of surprise costs can occur throughout project execution, and will create cost variances.
COST BASELINE
The project manager will work on a preliminary draft of the budget. This draft can then be reviewed with the main team members. Doing this will ensure the accuracy of the budget, but it will also help the main team members understand project specifics. Once the budget is finalized, it can then be taken to the project sponsor for approval. The approval itself will generate a cost baseline, or an approved and expected planned cost for the project. However, in reality, as the project is executed, there could be differences between the planned cost and the actual cost that the project incurs. The “variance” will be contrasted and compared with the baseline.
SOFTWARE PROJECT RISKS
The idea of Risk Management refers to the search for risks that have the potential to have an impact on the project and the creation of a plan of action to take in the event that any of the risks actually occur. I’m going to mention briefly some example risks.
Human Resource – Other organization may recruit your best programmers.
Quality – Quality may be sacrificed to achieve project completion.
Feasibility – The goal and objectives of the project may be too grand and unrealistic.
Technical – The project members may not know how to implement the project.
Expectations – Stakeholders may have unreasonable expectations.
Scope – There may be change requests filed outside the change request system.
Cost – Cost may get out of control.
Time – The original completion time estimate may have used the wrong assumptions and be wrong.
PROJECT EXECUTION
The phase where the project work takes place is called Executing. In project management literature, “Executing” is described as separate than the “Monitoring and Controlling” group. However, in the real world, the groups work hand in hand. As work is executed, then the results are monitored to verify that they meet the quality expectations, stakeholder expectations and so on. As part of project execution, the team is assembled, the kick off meeting is held, and work on the project deliverables begins. In the meantime, different types of meetings are scheduled. These include; budget meetings, risk meetings, change control meetings, project status meetings, and so on.
17 Execution – Project Kick Off
PROJECT KICK-OFF
The project kick-off meeting should be set up after the approval of the project plan. The sponsor should set up the meeting and the meeting should include the stakeholders, the sponsor and the project team. The project kick-off meeting is much more than a meeting that simply declares the start of a project and shouldn’t be underestimated in importance. The meeting accomplishes quite a few different important functions for the project. First, the meeting allows the team members to formally begin work on the project. Second, as the responsibilities of the team are outlined in front of the sponsors, it creates accountability. Third, everyone gets a chance to go over the project descriptions, methods, goals and objectives. Four, the project charter and the scope is discussed, which allows the project manager to maintain the direction and to defend against possible change requests. The project sponsor should sign the charter. The key stakeholders should sign the project scope. This sets up verification possibility that everyone has understood what has been discussed.
PROJECT EXECUTION
The phase where the project work takes place is called Executing. In project management literature, “Executing” is described as separate than the “Monitoring and Controlling” group. However, in the real world, the groups work hand in hand. As work is executed, then the results are monitored to verify that they meet the quality expectations, stakeholder expectations and so on. As part of project execution, the team is assembled, the kick off meeting is held, and work on the project deliverables begins. In the meantime, different types of meetings are scheduled. These include; budget meetings, risk meetings, change control meetings, project status meetings, and so on.
DEVELOPMENT PROCESS MODELS
Understanding the software development process can be challenging. The software development process features many different methodologies, models, activities, tools, and frameworks. The list of concepts is too long, and though they are important for a software project manager to be aware of, including them all would cause the course to drag on endlessly. After all, this is not a course on software development. For this reason, I have selected what I think is important to be aware of. I will start by providing some examples of development models, such as; Waterfall, Agile, and Spiral.
What’s important to understand is the “Why we need a software development process?” One of the things that should become apparent is that organizations use a software development process because they need IT development to be well defined, repeatable and predictable. Organizations need to create products for delivery to customers, and to do so consistently; they need to follow strict software development process. Let’s take a look at some models.
Waterfall – The waterfall model of development is a model broken up into phases. The phases are: requirements, analysis, design, coding, testing, and operations. Ideally, once deliverables have been signed off for a given phase, they should not need to be re-implemented.
Agile – Instead of relying mostly on written documentation, daily team meetings are the focus of Agile divides application development into modular components. Each component piece focuses on a set of requirements or features that the customer prioritizes. By dividing the work, a system can be delivered quicker, even if it is only partially complete.
Spiral – Under the spiral model, the project is broken down into subprojects, which are then categorized according to their risk weighting. By attempting to tackle the toughest risks first, it demonstrates that if those are possible, then the rest of the project will be much easier and will lead to success.
DESIGN AND PROGRAMMING
LOSING CONTROL OF CODE
On any software development project, programmers spend a lot of time designing and implementing their code. You would think that the great amount of time that they spend with their code, would make them an expert on their code, however they still lose control of their code. By lose control, I mean that the code often ends up messy and difficult to maintain. The project manager should try to discover whether the code is elegant or messy, and should ensure that the best quality programming practices are adhered to. Here are some common programming concepts to be aware of: broken builds, test-driven development, and re-factoring old code.
Broken Builds
Programmers need to program code, and then they need to unit test that code. After testing the code, the programmers need to deliver the build to QA. Sometimes it goes smoothly, and sometimes an argument develops between the lead programmer and the lead tester. The programmer’s work very hard to develop the code, and it can come as a bit of a shock when the QA reports that the software is too broken to be tested. This often happens because the strategies for testing which the programmers employ different than the strategies employed by QA. Whereas the programmers do unit testing, software testers take actions in the software that require many different units in the code to work together. One way to produce higher quality code, with fewer defects, is to adopt test-driven development.
Test-Driven Development
Under “test-driven development”, unit tests are created before the code is built. In this type of development, the programmer creates a test case that verifies an object, and then builds the object. The inputs, outputs, boundary cases, and error conditions are all defined by the time the test case is finished. The programmer will know how the object might fail, before even building the object. This means, that by having planned in the various ways the object might fail, when the software is finally built, the programmer will catch many more defects.
Refactoring Old Code
Many programmers don’t like to maintain old code because it can be a challenge to maintain. As the years pass by, many different developers patch the code, which lengthens and complicates the original design. One technique to consider for such code is called refactoring. Refactoring is a way to improve the design of the code without changing its behaviour. Programmers know that code that implements behaviour can be written in multiple ways. However, refactoring is about modifying the code to make it easier to maintain. The purpose of refactoring is to improve people’ ability to understand the code, without changing the behaviour of the code.
20 – Programming Instead Of Documentation
PROGRAMMING INSTEAD OF DOCUMENTATION
Organizations that produce software often have limited timeframes in which to produce their software. Consequently, many make the decision to prioritize programming over anything documentation related. Further, some organizations even see the idea of project management and the related techniques and tools as wasteful. After all, couldn’t the time spent having meetings and generating documentation be instead used for generating code? By minimizing or removing the administrative aspects of projects, and simply assigning as much code and as quickly as possible to the programmers, these organizations risk project failure. Without project management techniques, the team may design software that is not meeting the requirements of the users. The software may solve a different problem altogether or it may lack important features. Other errors could crop up, such as poor time estimates made on wrong assumptions. In short, many of the reasons as to why a project can fail, comes from the project management process, or lack of it, rather than the programming process. The project manager needs to be seen as important and valuable, otherwise, they will not be granted permission to do the things they need to do. Only by being seen as relevant will the project manager be able to strike a balance between time allocated for administration and the time allocated for programming.
SOFTWARE TESTING
Software testing involves an analysis of whether or not the behaviour of the software matches the original requirements specification document. How closely that “software conforms to the requirements” determines the quality. If the software does not behave in a way as described in the requirements specification, then that difference is said to be a defect. When a feature doesn’t match the requirements, than that feature is said to have a defect. Requirements engineering allows the synchronization between programmers and testers, enabling both professionals to work from the same language towards deliver software that is free of defects. A lot of the problems in the design of software originate from a poor requirements process.
UNIT TESTING
Code is made up of different units, such as “functions”. These different units need to be tested separately. Unit testing involves running “unit tests” on different units of the software to ensure correct operation. In addition, multiple aspects of the units must be verified. At the very least, four aspects need to be verified: 1) Unit performs functions in the right manner. 2) Unit can handle errors. 3) Unit can handle unexpected values. 4) Unit can handle boundary cases such as “null” and “zeros”.
NEGOTIATE FOR TESTING TIME
As the software project progresses, there will come a point when the software may appear to function correctly, but it may not yet be fully tested or ready for release. At such a point, it may be tempting to the less experienced leadership, to cut time away from testing and simply release the software. For example, whereas a programmer and project manager may understand the need to run comprehensive testing, a senior manager without such specialized knowledge may assume that if it appears to work fine than it probably is ready for release. The project manager should be ready to negotiate for the necessary testing time with the senior manager. As part of this negotiation, it is the project manager’s responsibility to explain the importance of the testing process to maintaining the necessary level of quality of a software project.
TEST-DRIVEN DEVELOPMENT
Test-driven development is a type of development where the programmer writes the code for a series of unit tests before programming the object. By writing simple unit tests in combination with a prototype object, the programmer is able to write better code. Approaching the problem from this perspective allows the programmer to understand the problem better, and by the time the actual object is to be written, the programmer will have a good grasp of the object to be programmed. The programmer will have determined the interface that is actually required and that the interface works effectively. Without coding the tests first and without building the interface first, and going right to the development of the object, the programmer runs the risk of coding an object based on an unusual interface, with a broken interface, or with an interface that is inadequate to provide the necessary functionality that the object would need implemented.
INSPECTIONS AND DESKCHECKS
The purpose of reviews is to save on time and on labour. After all, a good review can identify problems. And then these problems can be addressed soon on in the project life cycle, which is better than later on when it would be required to backtrack and redo a whole bunch of work. In software projects, a common type of review is called inspections. The goal of the inspections is to have all the inspectors reach a consensus or common agreement. The process is as follows. The inspectors meet to inspect a product. The inspectors are expected to bring with them an analysis of the defects that they have discovered. The inspectors will disagree on the product, until the defects are removed. So the goal is to remove the defects, so as to be able to approve the product. The inspection process does require approval, which is sometimes a bit much. Sometimes, a programmer will only need another programmer to quickly check over the work, without having a meeting and an approval process. This is where a desk check is handy. In a desk check, another programmer or programmers are given a copy of the product, and then the author is provided with a defect report.
RESISTANCE TO INSPECTIONS
A good project manager realizes that inspections are worth the effort. However, try telling that to your team! Many teams believe that inspections take too long, and will resist any attempt to try to implement inspections. They don’t see that there is a relationship between inspecting code and saving time. The reality is, if inspections are avoided, the team runs the risk of wasting time by having to redo the work. Inspections allow a team to find errors early on in the process, which saves time, as the work is then done properly from the beginning. The project manager’s role is to help the team understand the role of inspections and the time they can save. There are other benefits, which are gained via inspections. For example, when a programmer inspects another programmer’s work, this has a training benefit. There is a knowledge transfer that occurs as one reads the code of another and makes suggestions. Second, if a programmer were to leave the organization, the fact that other programmers are familiar with the code helps to the organization as there would still be programmers in the organization which could maintain the code. Third, in the event that the programmer needs assistance, there are now other programmers who are familiar with the code and are immediately ready and able to lend a helping hand. The benefits are numerous and not always immediately obvious.
WALKTHROUGH
“Walkthrough” is a type of review that is led by the author of the code. The review type is less formal and has no particular predetermined presentation format. The method of communication used is the one that is most effective and easiest to understand. Presentation slides are used to show the design or programing documents. The author is the person who designed the code and this familiarity makes them the ideal person to help others understand the code, navigate the code and hold a feedback discussion.
CODE REVIEWS
Code reviews involve a team analysis of a certain portion of a programmer’s code. The code is analyzed to ensure that it meets the design parameters as outlined by the requirements specifications. It could be that the code works, but it works in a different way than desired. Or perhaps it works, but it is not efficient and not optimized for best performance. In addition, code reviews are essential because they can be used to discover problems in a programmers understanding of the programming practice. With code reviews, programmers are able to learn from each other. Projects usually involve a lot of code, and reviewing it all would be far too time consuming. This is why, only certain portions of code should be chosen for the code review. Choosing a section of code that is bland and common would not be a good idea. There would likely be no defects in such code. The best code to choose would be code that is not commonly written, and that is both demanding and complex.
ATTITUDES AND IDEAS ABOUT TESTERS
Some workers hold the view that testers don’t really contribute much to the overall programming effort. The testers write little segments of code, or they run the code over and over without creating much in the way of deliverables. In addition, they often delay the release of software, when to a non-programmer often looks like complete and ready to go. And if the programmers have already tested the software, what use is it to have this “redundant” tester go over it again. These types of ideas or attitudes are wrong. It is the responsibility of the project manager to clear up such confusion. Explaining the benefits of testing and how that contributes to quality in software production, to those who are confused about software testing, will help.
Another confusing idea bout testers comes from the idea that some workers believe that software testing takes little or no skill. They make the assumption that if someone knows anything about software engineering, they would choose to be a programmer rather than a tester. Therefore, the inference is that anyone that is a tester must not be very good at programming. However, professional software testing takes professional ability and skill, and that is why highly qualified people often choose the testing profession. The project manager should help team members understand the importance and degree of professional ability that goes into being a good tester.
As part of testing, the tester must be able understand the requirements specification. With this understanding, they are then able to create a verification strategy for the software. Without rigorous and disciplined engineering training and approach, the tester would miss crucial perspectives and test conditions. The project manager needs to show that the role of the tester is crucial to the effort to produce software. In addition, testers are in the position to judge the software. With this in mind, programmers can feel uncomfortable as testers criticize their work. The project manager needs to show that the objective of the testers is to uphold quality, rather than to belittle, criticize or blame the programmer.
IT PROJECT QUALITY
Quality is something that we hear about from various types of people. We hear about it from sales people, from engineers, from businesses, from friends, from management and from many other sources. Quality is a common term used by companies to differentiate their products and services from those of the competitor. The achievement of quality provides individuals and companies with a competitive advantage. Quality is not only essential in life, but for our purposes, it is essential in project management. This leads us to the idea that is important to know what has quality and what does not. Let’s consider an example. Consider a comparison between two vehicles, a luxury vehicle and a mainstream entry-level vehicle. Consider that the luxury vehicle comes with many features and that the entry-level vehicle has a smaller and much more basic feature set. With this information in mind, which one would most people say has more quality? It is reasonable to assume, that most people would say that the luxury car has more quality because it has more features and it is pricier. However, this determination cannot be made on the basis of the size of the feature set and the implied price. In reality, reliability and dependability is key. It is likely that an entry-level car would be aimed at mass production, and would therefore be designed to include only the most reliable features. In software development, a system with many features could have a lot of defects. On the other hand, a simple piece of software could be designed in such an elegant and streamlined way that defects would be very hard to come by. When it comes to project management, ensuring the quality of the deliverable of the product is a good first step. But there is another consideration. It is not possible to ensure the quality of the deliverable, without also ensuring that the quality of the processes, which were used to come up with the deliverable.
BEING RESPONSIBLE FOR QUALITY
Project managers need to explain the responsibility that everyone has to maintain the level of quality on a project. When it comes to explaining quality to testers and programmers, it is important for the project manager to explain that quality is a common responsibility. Many programmers expect that the testers do all of the testing, and the testers expect that the programmers should deliver builds that have the majority of the defects resolved. Who is right?
A project manager should be clear and draw the line of where unit testing ends and where functional testing begins. The project manager needs to explain to the programmers to unit test the software and to not leave all of the testing work for the testers. The reason programmers need to unit test software is that they have a different outlook than the testers. The programmers put together the software according to how they imagine it could function or how they want it to function. On the other hand, testers test the software against the software requirements specification as outlined by the needs of the users. The approaches are different, and as a result, both professionals need to test the software.
The Quality Assurance team should receive code that has already been united tested successfully. The QA team doesn’t have access to individual modules, functions and classes. If there is an error there at the implementation level, it could remain hidden underneath the user interface. The QA team has access from the perspective of the “user”, and though they can test the software in complex ways by activating multiple units simultaneously and in different combinations, they can only do so from a user and not a programmer perspective. The build delivered to them must have already been tested at the component level such that higher level testing can then take place at the user level.
PROJECT CHANGE
CHANGE IN DIRECTION
A project that needs to change course midway through execution faces a much greater risk of failure than a project that stays the course according to the original plan. When a project has to make a major change in direction, there is a high probability that it will fail. Imagine a scenario where the client discovers that a critical feature is missing from the software. When the project team finds out about the oversight, they will feel demoralized and their productivity will drop. They will then have to re-plan, re-design, re-program and re-test new software that would contain the missing feature. Having to do the work twice is wasteful, risky, unprofitable, and disheartening. Proper planning is essential. Clients are not very technical people, and that is why communications with them must be kept as basic and as understandable as possible. Technical scope documents may describe complex features, but if they are not presented in an elegant and highly comprehensible manner, than they will confuse and lead to a possible misunderstanding of the features required.
CHANGE CONTROL
One of the difficulties of being a project manager, is making the right decision from the dozens of available options and proposed changes, which are continually presented. In a project, there can be many different people involved. Also, it is likely that the people all have different knowledge bases, types of experiences, and thought processes. The number of observations that can be made are numerous and varied. The result: throughout a project, many different proposals for change are presented to the project manager. A tester may notice conflicts between different requirements documents. A programmer may discover a better technology, system or approach to solve the problem. A CEO may want to change focus or direction. Changes can come from many different sources from within or from outside the organization. As such, the project manager cannot make decisions using only instinct, but needs a “well defined” and “scientifically rigorous”, “system”, to determine which changes to accept and which to deny. In project management terminology, that system is referred to as “change control”. Change control is a process that a company can use to filter out the poor change requests while accepting the strong change requests. Change control requires that the person requesting the change go through a process where they must justify the change. If insufficient justification is provided to compensate for the difficulty and risk that the proposed change introduces into the project, then the change is denied. The proposed changes are reviewed, tracked and recorded.
MONITORING AND CONTROLLING
The processes that are part of the Monitoring and Controlling process group, they ensure that work is performed according to the plan. Work takes place in the Executing stage, but if work diverges from the plan and issues and problems arise, then the project is rolled back to the planning stage for problem identification and resolution. Once problems are resolved the project can go back into “Executing” stage. If there are changes in scope, time and cost, the monitoring and controlling process will allow you to manage these changes. Also, the Monitoring and Controlling process group involves work with stakeholders to verify that the scope has met stakeholder requirements. There is also the element of reporting on project performance, which is part of this process group.
CLOSING OUT A PROJECT
After the deliverables are completed, the project will need to be closed. There are several critical items, which need to be addressed, as part of this project closure. First, a project report should be generated. This report will document project history and accomplishments. This report will help to convince the sponsor or the client that the project followed the plan and met objectives. Second, the project manager needs to demonstrate that the project has met all of the requirements outlined in the project scope. This demonstration should lead a sign off which will serve to provide proof that the project was completed and accepted. Third, the project will need to be transferred to the operations department. Fourth, the team members will need to be released from the project. Fifth, the documents generated throughout the project will need to be archived in storage.
What are the requirements?
- To have an interest in project management.
- To have an interest in software project management.
- To have an interest in IT project management.
- To have an interest in the development of professional management skills.
- An ability to handle topics of various complexities, from simple to complex.
What am I going to get from this course?
- Gain experience and insights into the project management practice.
- Improve your practice as a manager through the use of professional techniques.
- Absorb specialized terms, concepts, insights, principles and other relevant language. Improve your ability to discuss the project management role with your colleagues and display the required specialized knowledge.
- Make a smooth transition from a worker to project manager, and once a project manager, have the knowledge required to stay there!
- Become a better IT project manager, who is respected by subordinates, superiors and peers.
Who is the target audience?
- A project manager responsible for a software development project or IT project
- A project manager who has been put in charge of a project
- A project manager who seeks continuing professional development
- A team member who has recently been promoted to the project management role
- A programmer, designer, business analyst, tester or other member of a software team
- An aspiring project manager
- Recent graduates from business, computer science, engineering or other relevant programs
- A student who seeks to understand project processes and software project management
To see our Donate Page, click https://skillsgaptrainer.com/donate
To go back to our Home Page, click https://skillsgaptrainer.com
To see our Instagram Channel, click https://www.instagram.com/skillsgaptrainer/
To see our Twitter / X Channel, click https://twitter.com/SkillsGapTrain
To see our YouTube Channel, click https://www.youtube.com/@skillsgaptrainer
To see some of our Udemy Courses, click SGT Udemy Page