2020 Group Members Muhammad Usama shakeel FA16-BSE-017 Asif Ali Khan FA16-BSE-005 Mohsin Ali Khan FA16-BSE-055 Zameer Sagheer Mughal FA16-BSE-063 Sohail Akbar FA16-BSE-057 Assignment # 04 Group No.3 PROJECT MANAGEMENT IN SMALL SCALE SOFTWARE HOUSES Contents Abstract: ................................................................................................................................................................................. 3 Key words: .............................................................................................................................................................................. 3 1. Introduction .................................................................................................................................................................... 4 How to evaluate the project outcomes in following aspects: - Quality of products delivered - Customer satisfactions Organization benefits - Project team satisfaction................................................................................................................ 5 2. Background/Related work ............................................................................................................................................. 5 3. Study Design ................................................................................................................................................................... 6 Define Goal ......................................................................................................................................................................... 6 Identification of relevant papers ....................................................................................................................................... 8 Selection Criteria .............................................................................................................................................................. 10 Quality Assessment .......................................................................................................................................................... 10 Data Extraction ................................................................................................................................................................. 11 4. Findings (Answers to Research Questions) ................................................................................................................. 11 Q1. What is the project performance evaluation criteria in small scale software houses? .......................................... 11 Q2. Classification of critical factors for project success or failure in small scale software houses................................ 15 Q3. How to demonstrate relationship between applying methods, techniques and project success in small scale software houses. .............................................................................................................................................................. 20 Q4. How to evaluate the project outcomes in following aspects: - Quality of products delivered - Customer satisfactions - Organization benefits - Project team satisfaction ................................................................................... 28 5. Conclusion: ................................................................................................................................................................... 34 6. References: ................................................................................................................................................................... 35 PROJECT MANAGEMENT IN SMALL SCALE SOFTWARE HOUSES Systematic Literature Review for PROJECT MANAGEMENT IN SMALL SCALE SOFTWARE HOUSES Abstract: Small and medium-size enterprises (SMEs) involved in software development often experience problems in mastering their development process, especially smaller companies. This can result in a decreased efficiency leading to problems such as time/cost overruns or failing to address functional and non-functional requirements (reliability, performance, usability, etc.). Globally, this can reduce significantly the customer satisfaction and hamper the enterprise growth potential. In this paper, we report about a survey to assess more precisely which and how SMEs are affected by these problems. The survey was driven on small scales software houses lightweight standard focusing on very small entities (VSEs) developing software whose internal IT department is less than 25 people. This represents a very large portion of SMEs in business. In particular, survey results highlight the most frequent issues and how they are linked to some organization/project characteristics. The survey is based on a free online self-assessment consequently, in addition to identifying issues encountered by enterprises it is also possible to infer a set of quick-win recommendations to solve these issues. We could also cross-check the relevance of small scale software houses recommended tasks and activities in comparison with those already in place at companies participating to the survey. Our results are also compared with those reported by other surveys targeting both large and small companies. Key words: Project Management Small Project Management Small Scale Project Management Small Scale software House Software process improvement Small and medium-sized software Project Management Software process improvement Improvement models 1. Introduction Software process improvement is a demanding and complex undertaking. To support the constitution and implementation of software process improvement schemes and projects, the Software Engineering Institute (SEI) proposes a framework, the so-called IDEAL model, which consists of five phases and which provides a structured approach for continuous improvement. This model is based on the SEI’s experiences with their governmental and industry customers in the US. These are usually very large organizations. However, most software enterprises, even in the US, but more so in Europe and other parts of the world, belong to the category of small and very small software enterprises. Yet, although vital for both academics and practitioners in the field, insights about software process improvement in general and the use of such a model as IDEAL in minor organizations is still scarce The work presented in this article wants to contribute to that body of knowledge. We have therefore investigated the suitability of the IDEAL model for small software enterprises and report our experiences of deploying the approach in a young and small Danish software company. The approach was tailored to meet the organization’s needs and this resulted in the successful completion of a first improvement cycle. The aim of the undertaking was to change the practices in the involved organization, thus the research approach applied falls into the category of action research . The authors participated, each to a different extent, actively in the process as change agents and mentors for the intended alterations. In addition to the involvement in the project, observations, informal conversations, formal interviews, official meetings and document studies were used as methods for collection of the data, on which this article is based. The article is structured as follows. In the next section the IDEAL model is explained in more detail. Then, the course of the project and the application of the model are presented. Finally, the alignment process and the content of the adjustments and their impact on the improvement project as a whole are discussed and the case is reflected on the background of current knowledge about managing software process improvement as organizational change. Q1 What is the project performance evaluation criteria in small scale software houses? Q2 Classification of critical factors for project success or failure in small scale software houses Q3 How to demonstrate relationship between applying methods, techniques and project success in small scale software houses Q4 How to evaluate the project outcomes in following aspects: - Quality of products delivered - Customer satisfactions - Organization benefits - Project team satisfaction Overview: Software process improvement is a demanding and complex undertaking. To support the constitution and implementation of software process improvement schemes the Software Engineering Institute (SEI) proposes a framework, the so-called IDEAL model. This model is based on experiences from large organizations. The aim of the research described here was to investigate the suitability of the model for small software enterprises. It has therefore been deployed and adjusted for successful use in a small Danish software company. The course of the project and the application of the model are presented and the case is reflected on the background of current knowledge about managing software process improvement as organizational change. 2. Background/Related work Several studies have shown how difficult is to share Software Engineering knowledge. SE has been traditionally taught through lectures. Blackboards and slide presentations are used as a support to the explanations. In addition, students hould take part in a fictitious project, which has little or no connection to the traditional one to teach SE and also motivate students to engage in the learning process, that is, become active. Several authors have defined how to remove complexity in teaching se through reading and projects. The aim of active learning is to provide opportunities for learners to critically think about content through a range of activities that help prepare learners for the challenges of professional situations. In this sense, PIM involves deep learning, as it focuses on real-world problems and challenges and relies on problem solving, decision making and investigative skills. These characteristics are suitable for improving the teaching of Software Engineering. Learning SE and how to apply your approaches throughout a software project can be a key factor in being successful. However, the success of a project requires more than knowing SE and how to apply it, it requires input from a variety of groups including the client, the project team, the project manager, the organization, the producer and the end user. Each party has a role in defining and determining success and they all have specific tasks and responsibilities that they must fulfill in order to achieve success. Implementation of project will be managed by project team. Right management techniques are necessary for team to assure that planning, controlling and communication systems are all in place. Without these systems the coordination and control of all individuals and resources within the team is difficult. 3. Study Design Define Goal The main point of this chapter is to define the goal and scope of the project so clearly that measuring progress is easy, and that there is no ambiguity that the project goals have been achieved. There are several techniques and tools available to the project manager to define the goal and scope clearly. Among them is the Is / Is Not technique, and the SMART goal checklist. Upon completion of this chapter, the reader should be able to: • • • • • • Explain why project planning is valuable Describe the value and contents of a project charter, scope of work statement, and software project management plan Create useable goal and objective statements Explain how to make crisp clean boundaries around the project’s scope Describe the five project process steps for any project, and how they relate to the product processes of business and software development Show how the Project Charter, Statement of Work (SOW), Software Project Management Plan (SPMP), and Software Requirements Specification (SRS) relate to each other Identification of relevant papers IEEE Direct Science No. Paper Title Q1 Q2 Q3 Q4 Q5 Year ACM No. Paper Title Q1 Q2 Q3 Q4 Q5 Year Q2 Q3 Q4 Q5 Year SPRINGER No. Paper Title Q1 Selection Criteria We have selected the paper from the top 4 most reliable repositories: I. II. III. IV. Springer ACM IEEE Science Direct Our paper range form 2010-2020. Most of paper we have selected are related to our topic known as “Project Management on small scale software house”. We have validated all the data we have included in our systematic literature review and have no Redundancy in this SLR. Quality Assessment No of Reserach Papers 5 0 2010 2011 2012 2013 2014 Journal Paper 2015 2016 Conference Paper 2017 2018 2019 Data Extraction Research Strategy 4. Findings (Answers to Research Questions) Q1. What is the project performance evaluation criteria in small scale software houses? An incomplete vision of project performance is directly related to fulfilling the original goals of time, cost and quality. Therefore, the work of Baker, Murphy and Fisher (1983), which showed that broader performance criteria are used by professionals, plays an important role in various projects. They proposed the concept of perceived success when they observed in their study that projects that did not meet their original goals of cost, schedule and quality were not necessarily perceived as failed projects by the people involved in the development of the projects. Thus, a project's success is linked to the perception of those involved (stakeholders) regarding the performance of the project. Figure 1- Model of Project of Success. Adapted from Pinto and Slevin (1986) success of project management (process view) and product success (product view). The success of the process is linked to the classical aspects of performance (time, cost and quality technical specifications), stakeholder satisfaction and development, and quality management process. This view leads to the following performance criteria: • anticipate project requirements, meet project needs, use resources efficiently; • communicate effectively and resolve of cases in a timely manner; • establish effective coordination of and relationships between stakeholders, engage in teamwork and in participatory and consensual decision making; • minimize scope changes and eliminate disturbances in the organization (related to work process and culture); • complete project with no post-closing problems and identify and solve problems during project execution. The success of the product is evaluated using the following criteria: • achieves organizational objectives according to strategic buyer / project sponsor; • meets needs and purposes of users purposes and is appropriate for use; • meets needs of other stakeholders of the project product. Figure 2 - Importance of factors of performance over time. Adapted from Pinto and Slevin (1986) all the influences and can assess compliance with the overall objectives and benefits. Wateridge (1995) examined over 100 projects to determine the success criteria and constraints used in the design of information technology (IT).. While the author claims to have found broad consensus among stakeholders of IT projects, there is some disagreement regarding the inclusion of meeting deadlines and budgets within the definition of success criteria. The author noted a variation in the criteria used in the performances among projects considered to be successful and those considered to be unsuccessful. For projects deemed to be successful, meeting the established quality specifications and achieving commercial success were considered to be more important by project managers, while with respect to project failures, compliance schedules and budgets were the most cited factors that contributed to a lack of success. Users, in general, are more concerned with ensuring a project's end result. (*) Third parties include local and national authorities, media, environmental groups, general public, etc. Figure 3 - Scope of project success and success of project management. Adapted from Munns and Bjeirmi (1997) It is interesting to note the consistency of this result with that of Baker, Murphy and Fisher (1983), who also found that the factors that affect the perception of success are not (exactly) the same as those that affect the perception of failure. Wateridge (1995) also emphasizes the importance of establishing a priori criteria for evaluating performance among project stakeholders. He recalls that a manager is only able to treat adequately the constraints of project success when a consensus exists among stakeholders on the success criteria applied to the project.The concept of success used by Dvir et al. (1998) has two dimensions: benefits perceived by consumers and fulfillment of project goals (design). In contrast, Shenhar et al. (2001) do not recognize the existence of two distinct concepts of success - success and the success of product design - and instead defend the premise that the relative importance of the dimensions of project success change over time. They identify the following dimensions of success: • Project efficiency (meeting deadlines and budgets); • Impact on consumer (customer satisfaction and product quality); • Success of the business (revenue generation, profit share and other benefits derived by the mother organization); • Preparation for the future (developing organizational infrastructure and / or technology for the future). Q2. Classification of critical factors for project success or failure in small scale software houses. Critical success factors (CSFs) While in comprehensive literature reviews i.e. based on case studies, experience reports, research articles and books. We identified ten critical success factors Categories 88% Senior Management Commitment 1 71% Staff Involvement 2 53% Exprience Staff 3 53% SPI awareness and Implementation 4 41% Training and mentoring 5 35% Allocation of Resources 6 35% Communication and Collaboration 7 29% SPI goals and Objective 8 29% Organization Culture 9 29% Organization Politics 10 The above identified CSFs are describing below in details, Senior Management Commitment Senior management commitment is most cited factors in the available literature (Niazi et al , 2006 ; Dyba, 2005 ; Rainer and Hall, 2001 ; Stelzer and Melis, 1999 ; El Emam et al, 2001 ; Rickart, 1979 ; Montoni and Rocha, 2007 ; Woong, 2004 ; Goldenson and Herbslebs , 1995 ; Badoo and Hall , 2002) & Dorenbos and Combelles , 2004). These researchers use different key words to define the “management commitment” term, for example, higher management commitment, executive support, top down commitment etc. However, all of researchers tried to share their findings about the role of senior management commitment and its importance in Software process Improvement. Different group of practitioners belonging to industries with best practice concepts and approaches for successful implementation of SPI and initiative taken, is highlighted in their empirical studies results and, how truly commitment and involvement of senior management abled them for successful implementation of SPI initiative program was pointed out. To be successful in the SPI process the senior management should have a broader picture of their resources required to conduct the process improvement assessment initiative, and appropriately need to plan, sponsor, provide funding and accomplish the actions plan (Stelzer and Melis, 1999). The Goldenson and Herbslebs (1995) study shows that almost 100% create actions plans and 90% for Process Action Team (PAT) to assure the implementation of actions plans. This study also confirmed that the monitoring of the progress by higher management is the most vital factor in successful implementation of SPI. Staff Involvement Staff involvement is among a key factor which helps to facilitate successful SPI program. This is agreed by many researchers such as (Niazi et al, 2006 ; Dyba, 2005; Rainer and Hall, 2001 ; Stelzer and Melis, 1999 ; Hall et al, 2002 ; Montoni and Rocha, 2007; Woong, 2004 ; Goldenson and Herbslebs, 1995 ; Badoo and Hall, 2002 ; Dorenbos and Combelles, 2004). These authors explore different aspects of staff involvement CSF in their studies and provide some in-depth knowledge and idea about how the staff participation and involvement leads us to successful implementation of SPI and in the evaluation process; and assessment of its initiative in change management. The Dyba (2005) defined staff involvement factor as “the extent to which employees use their knowledge and experience to decide, act, and take responsibility for SPI and this is positively associated with SPI success” while, Stelzer and Melis (1999) defined staff involvement as “ the degree to which staff members participate in the improvement activities “. So, in the light of above researchers definitions it can be said that staff involvement is the amount of interest taken by the employees in the adoption of responsibility to participate in SPI initiative where they use their skills, experience and knowledge for successful implementation of SPI program and initiative. For successful SPI program, staff involvement is extremely essential that all the personnel belonging to software development should be encouraged for participation in the change process and this can be achieved by forming workgroups. The software organizations require promoting, engaging and maintaining collaboration within the workgroups and between Project teams. The involvement of the group’s members should be administered properly so that every staffs feel the improvement in their work and sense of responsibility of contributing towards the organization goals (Dyba, 2005 ; Goldenson and Herbslebs, 1995; Stelzer and Melis, 1999 & Guerrero, 2004). The workgroup address is the Key Process Area and, the scheme for the design enhancement under the guideline of SEPG. Experience Staff The number of authors on the basis of their collected sample studies data, emphasis on how a software process skills, experience and staff expertise can play a key role in successful implementation of SPI program. In experienced staffs, practitioners consider hurdle in SPI and emphasize to equip them with the necessary training that transfers the right SPI skills that enable them to mastery it in use. This training should make awareness in the in-experienced staff about the critical technologies that is required for SPI initiatives. The main goal for this training should be to transfer the knowledge of SPI inter-related activities with business objective and organization goals. (Niazi, 2009) Nonetheless, some of the authors defined lack of experienced staff as a barrier in SPI: • In the organization different staffs treat differently, some of them give more priorities and importance than others this is due to reasons based on their experience and expertise. The organization lacks experienced staff and due to these reasons, they recruit people who have just graduated from the universities and don’t have previous experience. This skills and expertise continuously need to be improved and increased by means of training. (Rainer and Hall, 2003) • Due to lack of prior significant development experience of the change agent, who is engaged in SPI, their resulted approach towards process improvement is unrealistic and impractical. When such change agents try to implement a particular process, model or approach fails to tailor it that is suited to organization culture and aligned with organization business goals. Because, they don’t understand themselves, the software development process and in what context they used it. This leads towards failure and the results, which are achieved through the process, is neither accepted nor followed. (Moitra, 1998) SPI practitioner said that process initiative could only be successful if the staff involved in the process has detail and comprehensive understanding of SPI process and related to business. Experienced staff should need to be involved in SPI initiative because, they have all the necessary skills, experience, knowledge and firsthand experience with SPI implementation. By involving them, we can avoid re-documentation and real issues can be resolved on the spot. Below mention are some of the guidelines suggested by the practitioner for successful implementation of SPI. • Only those people need to be selected for the SPI activities that have good record of accomplishment of different SPI projects. • Organization should need to develop a well-written training policy according to their needs for SPI training. Responsibilities of each member should be clear and the member should be assigned SPI implementation activities. • • A mechanism for monitoring the SPI progress against the each staff members should be established and maintained. (Niazi ,2009) SPI awareness and Implementation methodology According to Niazi (2009) to fully understand the benefits of SPI, there is need to sponsor the SPI awareness program i.e. “ROI and impact”, practitioner belief that SPI implementation is basically taking on board the organization best practices. Consequently, it is essential to address the SPI awareness activities and transfer the share knowledge among different groups who are actively engaged in process activities (Niazi, 2009). In the SPI initiatives process program all the stakeholders should get involved and, comprehensive awareness and its benefits should be communicated to them. Because, the SPI implementation cannot be successful if adequate awareness was not provided to all the stakeholders in advance. In order to avoid barrier in SPI implementation, practitioner suggested below awareness guidelines • The benefits achieved through SPI implementation need to be communicated before the implementation process. • • • Higher management needs to be informed about the resource required and the amount of long benefits received. The role and responsibilities of staff members should be clear before implementation and, proper planning should be completed in order to manage and carry on SPI awareness events within the organization. Planning is also required to make SPI an organizational culture In order to avoid barrier in SPI implementation, practitioner suggested the following guidelines: • Technologies (such as tools for planning, monitoring and reporting projects ) should be used while developing SPI implementation methodology • In the pilot projects, SPI implementation methodology should be tested and staff member should be convinced with the performance of methodology. • Necessary training should be provided that transfers the appropriate skills and understanding that provide surety of successful use of methodology. • Methodology needs to be continuously evaluated with the aim to implement in the whole organization. (Niazi ,2009) Communication and Collaboration Communication and Collaboration are considered to be amongst the most influential factors, which affect the SPI process. Dyba defined these factors as: “Degree to which communication efforts precede and accompany the improvement program (communication) and degree to which staff members from different teams and departments cooperate (collaboration)” The lack of effective communications occurs when the change agent and the management are not able to communicate effectively the benefits achieved from the process improvements. Consequently, staffs involved in the mechanism don’t have clear information about their contribution, roles and the achievements. When the change initiative happen, people who are involved in the process always want clear answers of “the reasons for change” and “benefit they get” from the process initiative (Guerrero, 2004). The problem of inadequate cooperation among the teams and divisions occur in software companies like QA teams that are not suitably well involved in the development process. Thus, conquering process improvement activities stresses collaboration and, the collaboration project includes: “Joint process descriptions, workshops, and special interest groups. Joint activities help staff members discover unexpected similarities in products and processes.” Majority of SPI practitioner’s belief that inadequate supply of staffs, time and other resources are the major barriers in successful SPI implementation (Hall et al, 2002). Management often fails to understand the real investment of the resources required for process initiatives and often agree without having a clear-cut picture of the resources required. In practical terms, some of the management does not consider SPI as an actual or separate project. Thus, they hesitate to allocate resources. Niazi quoted some Authors and studies given below who consider that lack of resources is the main barrier in SPI implementation: • • • Florence discuss in the lesson learned , MITRE Corporation succeeded to achieved CMM level 3 due to adequate level of resources provided but, fails to achieve CMM level 4 due to the reasons that the resources were not provided as required. Kautz and Nielsen discussed SPI implementation and thought that it did not succeeded because the project managers are not willing to provide resources for their own projects and, for others improvement activities. Laporte and Trudel in Lesson learned from Oerlikon Aerospace described that it is important to estimate and provide resources. Otherwise, announce end of project and discontinue adopting SPI program. (Niazi , 2009) SPI objectives and goals It is necessary for organization to set realistic & relevant objectives and goals for SPI. These objectives need to be crystal clear and, SPI managers need to communicate to all the actions groups within the organization. Establishing the realistic objectives means that goals seem to be achieved in the near future and its objectives and goals are not too ambitious. It demand that the expectations should be clear and the expected results need to be communicated at all the levels of the organization (Stelzer and Melis, 1999 ; Becham, 2003). “.…Therefore, successful SPI program is one, in which SPI goals and policies have been clearly aligned with business goals, identifying the nature and direction of any SPI actions” (Dyba, 2005). The result of this combined effort towards the “common objectives”, ”to focus energy” and “to motivate people”. These factors citied 44% of the ISO cases and 87% of the CMM cases. Mangers who don’t set the realistic objectives or too much goals merely dishearten their subordinate staff. The organizations that while taking the process initiatives do not defined relevant objectives and goals basically, in the long term, end up on fuzzy goals. This approach neither help fully to motivate the staffs nor for successful improvement efforts. (Stelzer and Melis, 1999) Organizational Politics Several authors consider politics as barrier in SPI implementation because SPI aim is to bring a change in the organization and people do often resist the change. This is because SPI initiatives goals may suit to one group’s goals but collide with other groups or teams goals. The reason is that the organization comprises of different groups and they have different priorities and goals that do not match with the SPI initiatives goals and this leads to oppositions from those people. ”There are many factors that can trigger organization politics, such as reallocation of the resources, promotions opportunities, low trust, times pressure, and role ambiguity.” (Niazi, 2009). The authors Goldenson and Herbsleb (1995), El-Emam et al (2001) and Becham (2003) also found that organizational politics is very common in the organization and create hurdle in successful process implementation activities. Author Moitra also identified the underlying problems and difficulties of SPI change management process and stated that politics is one of the main cause in change management efforts and a strong barrier in successful process improvement initiatives (Moitra, 1998). Organizational Culture Culture difference exists between different countries that are not necessarily suited or accepted by people living in other countries. Moreover, specific cultures adopt, without considerations of that organization, original values from these countries customs and practice. These may be found as a problem in existing organization’s cultures (Becham, 2003). Organizations will continuously face problems in implementation and deploying of best practices; majority of these problems belong to “people, group, team and community culture and behavior” (Dorrenbos and Combelles, 2004). All these needs to be considered when SPI improvement initiative steps should be taken. So that any suggestion, implementation and deployment activities do not adopt any such change of management methods which oppose the culture. The failures in consideration of culture impact while designing the change management program, leads towards process adoption by the groups or people in unproductive manner or, totally neglect the adoption. This consequently affects the process improvement program and overall productivity (Guerrero, 2004). According to Moitra neglecting to anchor change in corporate culture is main reasons for failure in process improvement related change efforts. (Moitra, 1998) Q3. How to demonstrate relationship between applying methods, techniques and project success in small scale software houses. Helpful Project Management Methods and Techniques Before we dive in, you should remember that all of these methods will help you organize and structure your project. There’s no right answer. Your chosen method depends on you and your project. I. Work Breakdown Structure (WBS) A WBS transforms big project activities into chunks of manageable tasks you and your team can easily understand and complete. So if you were constructing a house, like in the example above, you’d divide the work into segments such as: internal work, external work, and building the foundation. From there, you’d break down the work further into work packages, based on levels and task dependencies. Who should use WBS? WBS can be used as a project management technique, but it can also be a tool, regardless of the technique you end up choosing. It will help you understand all the tasks and resources that go into producing the final deliverable. How to get started? Start from the final deliverable defined by the project, and then define the tasks you and your team will need to complete in order to finalize the project. Divide the tasks into work packages. Stop only when you’re sure that you can’t break down the lowest- level work packages into smaller chunks of work. Gantt Charts – One of the First Project Management Techniques Gantt charts have been around for a very long time, and they’re still a great project management technique for beginners and pros alike. It’s another technique that emphasizes visuality. It’s a visual representation of all the tasks your team has to complete in order to wrap up the project, visualized together with time spans. You’ll be able to see task dependencies, how long each task will take, as well as how its duration will affect the start dates and deadlines. Who should use Gantt charts? While you can use Gantt charts as a standalone project management technique, you can also use them as an organizational tool, regardless of your chosen method. How to get started? The majority of project management tools offer Gantt chart views, so all you have to do is enter the data, and you’ll get a visualization immediately. It’s good to have a Work Breakdown Structure prior to that, so you can accurately define tasks you’ll add to your Gantt chart. II. Critical Path Method (CPM) The Critical Path Method is one of project management techniques used to accurately schedule all project activities. What you’ll be actually doing is calculating the critical path – the shortest route to project completion, and arranging tasks accordingly. It’s also a great way to establish task dependencies. You can combine CPM with PERT (Program Evaluation and Review Technique) to create three task completion time estimates: • • • Shortest amount of time Realistic amount of time The longest amount of time Who should use the Critical Path Method? CPM is best suited to more complex projects with a lot of task dependencies. However, just like with WBS and Gantt Charts, you can use them as tools, not just as project management techniques. How to get started? Define all the tasks that have to be completed. Then, establish task dependencies (Task B can’t be completed until Task A is completed), and create diagrams for different duration estimates. III. Waterfall / Linear Waterfall is one of the oldest project management techniques. If you use this project management technique, activities and tasks will linearly flow through 5 phases: • • • • • Requirements (Get all the necessary documentation) Design (Use a WBS to create a list of tasks) Implementation (Complete tasks) Verification (Review the deliverables) Maintenance (Maintain and modify if necessary). Who should use the Waterfall method? Waterfall works great for projects with distinct phases that require very few iterations throughout the project life cycle. If you think you’ll need to modify certain things and re-discuss the scope or the budget of the project, Waterfall is not for you. How to get started? Make a list of all the resources and deliverables you’ll need in each phase. Preparation is key – make sure you have everything covered in the first, project initiation and requirements, phase. Kanban – The Simplest Project Management Technique IV. Kanban is one of the easiest project management techniques for first-time project managers. The whole philosophy is in creating three columns: • • • To-do Doing Done Then, you and your team can simply shift tasks from one column to another as you complete them. Who should use Kanban? Anyone. It’s great as a tool, or as a stand-alone project management technique. It’s particularly successful for simpler projects, or project teams that are prone to multitasking. How to get started? We recommend getting visual project management software which offers Kanban boards. Then, make a list of tasks, and assign them to different team members. When you complete a certain task, move it to the ‘Done’ column. V. Scrum – Best Agile Project Management Technique Finally, if you want to make sure every project deliverable comes out phenomenally, you should consider using Scrum, one of the most popular Agile methodology techniques. With Scrum, you’ll be working in sprints. During each sprint, you’ll work on a particular deliverable/feature. Sprints shouldn’t last longer than 2 weeks, and you should hold daily status update meetings. After the sprint, you should hold a review meeting, make suggestions for improving the next sprint, and keep going. It’s as simple as that! Who should use Scrum? Primarily, software development project teams, and project teams that work on complex projects requiring multiple iterations throughout the project life cycle. How to get started? Break down the project into specific deliverables / features. Work on one deliverable at a time during your sprint, and schedule them with task dependencies in mind. Ways To Measure Project Success Project managers often wonder if they are measuring the right things on a project. It's difficult to know how much time to spend evaluating past performance and how much time to spend on keeping the work moving forward. Of course there are many indicators of project success, but what do you need to be measuring while the project is in motion? At various points during the project you want to evaluate five points: schedule, quality, cost, stakeholder satisfaction and performance against the business case. You should be doing this informally anyway. A formal project evaluation is of use during the end of a phase or stage as it can give you a clear indication of how the project is performing against the original estimates. This information can then be used to grant (or withhold) approval from moving on with the next chunk of work. Let's look at the five items you should be evaluating. I. Schedule Project management success is often determined by whether or not you kept to the original timeline. Experienced project managers know how hard that is, but it's a little bit easier if you continually evaluate your progress as you go. You'll update your project schedule regularly - I recommend at least weekly. The schedule evaluation is something you can do more formally at the end of the stage or phase, or as part of a monthly report to your senior stakeholder group or Project Look at your major milestones and check if they still fall on the same dates as you originally agreed. Work out the slippage, if any, and how much of an impact this will have on your overall project timescales II. Quality The end of a project phase is a good time for a quality review. You can check both the quality of your project management practices - are you following the change management process every time and so on - and also the deliverables. A quality review can evaluate whether what you are doing meets the standards set out in your quality plans. Best find out now before the project goes too far, as it might be too late to do anything about it then. III. Cost Many executives would rate cost management as one of their highest priorities on a project, so evaluating how you the project is performing financially is crucial. Compare your current actual spend to what you had budgeted at this point. If there are variances, look to explain them. You can use a project dashboard to check your actual spend in real time. You'll also want to look forward and re-forecast the budget to the end of the project. something it is better to know about now. IV. Stakeholder Satisfaction Your wider team - your stakeholders - are essential in getting much of the work done, so it's worth checking in with them. Find out how they are feeling about the project right now and what you could be doing differently. This is a difficult measure to document statistically, although there's nothing to stop you asking them for a rating out of 10. Even if you are evaluating their satisfaction subjectively, it is still a useful exercise. If you notice that stakeholders are not fully supportive, you can put plans in place to engage them thoroughly to try to influence their behavior. V. Performance to Business Case Finally, you'll want to go back to the business case and see what you originally agreed upon. How is your project shaping up? Check that the benefits are still realistic and that the business problem this project was designed to solve does still exist. It happens - project teams work on initiatives that sound great but by the time they are finished the business environment has moved on and the project is redundant. No one bothered to check the business case during the project's life cycle and so no one realized that the work was no longer needed. Don't work on something that nobody wants! Check the business case regularly and evaluate it in light of the current business objectives. You can add other items to this list. In fact, it should reflect what is important to you and your team - you should be evaluating things that matter, so feel free to add extra element or ditch some of the ones that you are less worried about. If you need help working out what's important, this article about how to set up project tracking will help. Q4. How to evaluate the project outcomes in following aspects: - Quality of products delivered Customer satisfactions - Organization benefits - Project team satisfaction We can Evaluate the Project outcomes in following ways: Quality of Product Project quality is a key determiner of customer satisfaction...which in turn is a key determiner for project success. Therefore, nothing about quality should be taken lightly on the project. Before a project manager can plan for quality, he must know what the quality expectations are. Specifically, what are the quality standards of the performing organization and which quality standards are applicable to the project? As part of the planning processes, the project manager and the project team must identify the requirements of planning, determine how the requirements may be met, and identify the costs and time demands to meet the identified requirements. One of the key principles of project quality management is that quality is planned in, not inspected in. Planning for quality is more cost-effective than inspecting work results and doing the work over, or correcting problems to adhere to quality demands. The project manager must consider the cost of achieving the expected level of quality in contrast to the cost of nonconformance. The cost of quality includes training, safety measures, and action to prevent poor quality. The cost of nonconformance can far outweigh the cost of quality: loss of customers, rework, lost time, lost materials, and danger to workers. Results of Quality Control Quality control should, first and foremost, result in quality project output. Next, it should also promote quality improvement. The project manager and project team, based on the results of the tools and techniques to implement quality control, apply corrective actions to prevent unacceptable quality and improve the overall quality of the project management processes. And keep in mind that these quality tasks must also be part of your project schedule that you revise and track using a tool like Seavus’ Project Viewer in conjunction with MS project. The corrective actions the project manager and the project team want to incorporate into the project may require change requests and management approval. The value and importance of the change should be evident so the improvement to quality is approved and folded into the project. In addition to quality improvement, there are other results of quality control: Acceptance decisions. Results of work are either accepted or rejected. Rejected items typically mean rework Rework. Nonconformance to quality results in rework. Rework costs time and money and contributes to projects being late, over budget, or both. It is always more cost effective to do the work right the first time than to do it correct the second. Completed checklists. If the project is using checklists to confirm the completion of work, then the completed checklists should become part of the project records. Some project managers require the project team member completing the checklist to initial the checklists as whole and complete. Process adjustments. When results of inspections indicate quality is out of control then process adjustments may be needed to make immediate corrective actions or planned preventive actions to ensure quality improves. Process adjustments, depending on the nature of the adjustment, may qualify for a change request and be funneled through the Change Control System as part of integration management. Customer Satisfaction What is customer satisfaction? When we have a great food experience at a new restaurant, we usually want to go back. Positive evaluations result in greater customer satisfaction, which leads to customer loyalty and product repurchase. That’s a customer satisfaction definition in a nutshell. But on closer inspection, customer satisfaction is more than simply a link in a chain that leads to more sales. 4 key customer satisfaction metrics So how do we effectively measure customer satisfaction? Here are 4 key customer satisfaction measurements that are critical to your business success. They take into account the different dimensions of customer satisfaction, such as affective (emotional) and cognitive (rationally judged) reactions to a product or service and behavioral intentions (such as likelihood to recommend or repurchase) as well as taking overall scores of satisfactions as judged by the respondents. 1. Overall Satisfaction Measure (Attitudinal) Example question: Overall, how satisfied are you with “La Jolla Grove restaurant”? This question reflects the overall opinion of a consumer’s satisfaction experience with a product he or she has used. The single greatest predictors of customer satisfaction are the customer experiences that result in attributions of quality. Perceived quality is often measured in one of three contexts: • Overall quality • Perceived reliability Extent of customer’s needs fulfilled It is commonly believed that dissatisfaction is synonymous with purchase regret while satisfaction is linked to positive ideas such as “it was a good choice” or “I am glad that I bought it.” • 2. Loyalty Measurement (Affective, Behavioral) Example question: Would you recommend “La Jolla Grove restaurant” to your family and friends? This single question measure is the core NPS (Net Promoter Score) measure. Customer loyalty reflects the likelihood of repurchasing products or services. Customer satisfaction is a major predictor of repurchase but is strongly influenced by explicit performance evaluations of product performance, quality, and value. Loyalty is often measured as a combination of measures including overall satisfaction, likelihood of repurchase, and likelihood of recommending the brand to a friend. A common measure of loyalty might be the sum of scores for the following three questions: • Overall, how satisfied are you with [brand]? • How likely are you to continue to choose/repurchase [brand]? • How likely are you to recommend [brand] to a friend or family member? A series of Attribute Satisfaction Measurements (Affective and Cognitive) Example question: How satisfied are you with the “taste” of your entre at La Jolla Grove? Example question: How important is “taste” in your decision to select La Jolla Grove restaurant? Affect (liking/disliking) is best measured in the context of product attributes or benefits. Customer satisfaction is influenced by perceived quality of product and service attributes, and is moderated by expectations of the product or service. The researcher must define and develop measures for each attribute that is important for customer satisfaction. Consumer attitudes toward a product developed as a result of product information or any experience with the product, whether perceived or real. Again, it may be meaningful to measure attitudes towards a product or service that a consumer has never used, but it is not meaningful to measure satisfaction when a product or service has not been used. 3. Intentions to Repurchase Measurements (Behavioral Measures) Example question: Do you intend to return to the La Jolla Grove restaurant in the next 30 days? When wording questions about future or hypothetical behavior, consumers often indicate that “purchasing this product would be a good choice” or “I would be glad to purchase this product.” Behavioral measures also reflect the consumer’s past experience with customer service representatives. Satisfaction can influence other post-purchase/post-experience actions like communicating to others through word of mouth and social networks. Additional post-experience actions might reflect heightened levels of product involvement that in turn result in increased search for the product or information, reduced trial of alternative products, and even changes in preferences for shopping locations and choice behavior. Organization benefits Projects and programs deliver benefits and drive strategy. This is a fact not always recognized by organizational leaders who are more focused on issues of cost and ROI than on the execution of projects. Benefits realization is a way to change that thinking, underscore how projects and programs deliver benefits to the business, and enable the necessary change. Adopting benefits management can help organizations increase the value of their investments. It requires purposeful attention to which projects and programs are approved—and why. It facilitates more effective decision making about investments. In fact, organizations with high benefits realization maturity waste 67 percent less money than those with low maturity, because they have better project performance. “It’s central to use benefits to decide which project ideas to invest in,” said Chris Lawler, PfMP, Manager, Project Portfolio Office, Mater Health Services. “They need to be part of the concept brief and business case and, though a temporary project will deliver the outputs, the permanent part of the organization needs to own benefits, be accountable, be measuring, then actively use those measures to make adjustments or to even terminate a project that will not create the desired value.” Despite the proven value of benefits management, the data from our 2016 Pulse of the Profession® reveals that a staggering 83 percent of organizations lack maturity with benefits realization, raising myriad questions about how they understand the business value of projects and programs. Our research further confirms that this lack of maturity may be contributing to projects—including strategic initiatives—failing to achieve their original goals and business intent; and that identifying benefits as part of the business case, even before the start of a project, improves outcomes. Specifically, 45 percent more projects meet original goals and business intent in organizations with high maturity in benefits realization, compared to those with low maturity. This translates to significantly fewer dollars wasted (see Figure 1). Those front- end discussions also help organizations understand a project’s benefits, even when they are not immediately realized. Some benefits, especially the more intangible, may not come to fruition for several years. So measuring return requires a longer-range view of related business activities. Project team satisfaction The evaluation of team satisfaction is just as important as the assessment of customer satisfaction. While there is a lot of research available on customer satisfaction this is not the case for the question: how satisfied are project team members with the project management and the project results? However, it is essential to know how our team members evaluate project results, project management, leadership, and the team work because their “inside views” can give us valuable suggestions where we can improve our project management process, leadership behavior, the environment of “healthy” team dynamics, and much more, for our future projects. By the term “team satisfaction” we mean the satisfaction of team members of the project team. As with customer satisfaction, here we also suggest to use interviews with individual team members in case of smaller project teams of up to twelve people, and questionnaires for larger teams. Both, interviews and questionnaires should cover team work and leadership issues as well as work content and results in all phases of project management. Team work or collaboration within the team Here we want to cover aspects of team work and group dynamics of the core project management team as seen by the team members. The following questions of a team satisfaction survey include the project manager as a team member with his / her special role as team leader. • Did we set and communicate clear goals for all of our discussions? • Did we consistently follow those goals? • Did we set and agree to rules for our cooperation and communication? • Did we consistently follow those rules? • What did we do for our cross-cultural understanding? • Did we respect each other personally and in terms of expertise? • Did we listen to each other by clarifying unclear points and asking appropriate questions? • Did we assign all necessary roles? • What did we do for our development as a team? • How did we set up the information flow within the team? • How did we make decisions? • Did we include all necessary team members in the problem solution processes? • Did we include all necessary team members in the decision making processes? • How did we deal with tension or conflict? • How did we deal with mistakes (hiding them, blaming each other, learning from them, etc.)? • Did we establish a culture of feedback and constructive criticism among all team members? • How well did we communicate with project participants and stakeholders outside the team? • If applicable, how well worked our virtual team communication and collaboration? 5. Conclusion: So far, the survey has confirmed previously reported factors explaining why SME are challenged in mastering the maturity of their IT developments. It has also more precisely highlighted interesting facts. It also tends to show that SME are quite aware of their maturity level and are willing to improve it (a large majority of SME asked to be kept informed although it was not mandatory). A current limitation is the relatively small number of answers, which is also bound to its relatively small current geographical scope. Our plan is now to extend our survey to other countries and, based on the larger set of answers, to study if the same observations are confirmed or need to be revised. It takes about 15 minutes to complete and provides quick win recommendations. We warmly encourage you to spread the information to any SME you know that might be interested. 6. References: Brodman, J. D., D. L. Johnson (1994). What Small Businesses and Small Organizations say about the CMM. In Proceedings of the 16th International Conference on Software Engineering, IEEE Computer Society, pp. 331-340, May 1994. Kautz, K. (1999). Making Sense of Measurements for Small Organizations. IEEE Software, Vol. 16, No.2, pp. 14-20. Argyris, C., D. A. Schoen (1991). Participatory Action Research and Action Science Compared. In Whyte, W. F. (ed.), Participatory Action Research. Sage, Newbury Park, Ca., USA. McFeeley, B. (1996). IDEALSM : A User’s Guide for Software Process Improvement. Handbook CMU/SEI- 96-HB-001. Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PE, USA. Iversen, J., J. Johansen, P.A. Nielsen, and J. Pries-Heje (1998). Combining Quantitative and Qualitative Assessment Methods in Software Process Improvement. In Baets (ed.), Proceedings of the 6th European Conference on Information Systems (ECIS), Aix-en- Provence, France, pp. 451-466, June 4-6, 1998. Westergaard Hansen, H. , K. Thaysen (1998a). NP - Assessment Process Report (in Danish). University of Aalborg, Institute for Electronic Systems, Department of Computer Science, Denmark. Westergaard Hansen, H., K. Thaysen (1998b). Process Improvement in a Small Danish Software Company (in Danish). MSC Thesis, University of Aalborg, Institute for Electronic Systems, Department of Computer Science, Denmark. Kautz, K., K. Thaysen (2000). Knowledge, learning and IT Support in a Small Software Company, in Proceedings of BPRC CONFERENCE on 'Knowledge Management: Concepts and Controversies' 10-11, February, 2000: University of Warwick, Coventry, UK. Rogers, E. M. (1983). Diffusion of Innovations (3rd edition). The Free Press, New York. Kautz, K. (1999). Software Process Improvement in very Small Enterprises: Does it pay off? In Journal of the Software Process – Improvement and Practice, Special Issue on Organizational Change with Software Process Improvement, Vol. 5. Borum, F. (1995). Strategies for Organizational Change (in Danish). CBS Publishing Company. Copenhagen, Denmark. Boehm, B.W. Software Engineering Economics. Prentice-Hall Inc., Englewood Cliffs, NJ, 1981. Curtis, B., Kellner, M.I. and Over, J. Process Modeling. Commun. ACM 35, 9 (1992), 75–90. Deephouse, C., Mukhopadhyay, T., Goldenson, D.R. and Kellner, M.I. Software processes and project performance. Journal of Management Information Systems 12, 3 (1996), 185– 2003. Dion, R., Process improvement and the corporate balance sheet, IEEE Software 10, 4 (July 1993), 28–35. Fox C. and Frakes, W., The Quality Approach: Is it Delivering? Commun. ACM 40, 6 (1997), 25–29. Gopalakrishnan, S., Kochikar, V.P. and Yegneshwar, S. The offshore model for software development: the Infosys experience. In Proceedings of the ACM SIGCPR Conference on The Virtual Workplace: The Impact on Individuals, Organizations and Societies. (Denver, Colorado).April 1996. Herbsleb, J., Zubrow, D., Goldenson, D., Hayes, W., Paulk, M., Software quality and the Capability Maturity Model, Commun. ACM 40, 6 (1997), 30–40. Humphrey, Watts, Snyder, Terry R. and Willis, Ronald R., Software process improvement at Hughes Aircraft, IEEE Software 8, 4 (July 1991), 11–23. Kraut, R.E. and Streeter, L.A. Coordination in large scale software development. Commun. ACM 38, 7 (1995), 69–81. Krishnan, M. S., C. H. Kriebel, S. Kekre, and T. Mukhopadhyay, An empirical analysis of cost and conformance quality in software products. Management Science 46, 6 (June 2000)745–759. Mukhopadhyay, T. and Kekre, S. Software effort models for early estimation of process control applications. IEEE Transactions on Software Engineering 18, 10 (1992), 915–924. Paulk, M.C., Curtis, B., Chrissis, M.B. and Weber, C.V. Capability Maturity Model for Software, Version 1.1. Software Engineering Institute, CMU / SEI-93-TR-24, (Feb. 1993).