M.tech 2 sem MTCS042 Software Project Planning & Management

Software Quality Metrics

Software metrics can be classified into three categories −

·        Product metrics − Describes the characteristics of the product such as size, complexity, design features, performance, and quality level.

·        Process metrics − These characteristics can be used to improve the development and maintenance activities of the software.

·        Project metrics − This metrics describe the project characteristics and execution. Examples include the number of software developers, the staffing pattern over the life cycle of the software, cost, schedule, and productivity.

Some metrics belong to multiple categories. For example, the in-process quality metrics of a project are both process metrics and project metrics.

Software quality metrics are a subset of software metrics that focus on the quality aspects of the product, process, and project. These are more closely associated with process and product metrics than with project metrics.

Software quality metrics can be further divided into three categories −

• Product quality metrics
• In-process quality metrics
• Maintenance quality metrics

Product Quality Metrics

This metrics include the following −

• Mean Time to Failure
• Defect Density
• Customer Problems
• Customer Satisfaction

Creating Strategic Metrics

The most powerful motive for creating strategic metrics is to improve the focus of your team. Measurement must be continuous, so a well-run organization needs to generate monthly financials and track metrics for SOs on a regular basis. The ongoing measurement and regular reporting serve to reinforce the drive to achieve strategic objectives and track progress toward the company’s goals.

So how do you establish strategic metrics to guide your long-term planning and minimizes entropy? First, consider that metrics are made up of measurements against a target or goal. To create clarity around desired outcomes, apply measurements that make sense toward a target goal. If a strategic objective is to increase sales, then use a simple metric like the increase in sales volume. Also, create benchmarks to make the goal achievable over time, rather than setting an unspecific strategic objective such as “increase sales by 15 percent.” Break the goal into measurable milestones, so your metrics become an increase of 1 percent the first month, 2 percent the second month, 5 percent the third, and so on to achieve the strategic objective. Adjust the targets as needed to achieve and even exceed your strategic goals.

Strategy-Based Performance Metrics

The most critical metrics for a business capability focus on the strategy for the business solution.  (Our deliverable for such strategy is called a Policy Charter.)  These metrics aim toward assessing the success (performance) of the strategy on a continuing basis.  Strategy-based metrics fall into two categories:  goal-based and policy-based.

People and Organizational Issues

POI focuses on interactions between people and technology, including designing, implementing, and deploying safe and usable health information systems and technology. The POIWG addresses issues such as how systems change us and our social and clinical environments, how we should change them, and what we need to do to take the fullest advantage of them to improve individual and population health and health care. As well as, to support healthcare providers, patients, and all other stakeholders, our members strive to understand, evaluate, and improve human-computer and socio-technical interactions.

We bring varied perspectives, methods, and tools from the humanities, social and cognitive sciences, computer science and informatics, and business disciplines to patient safety, workflow, collaborative work and decision-making, human-computer interaction and human factors, project and change management, adoption and diffusion of innovations, usability, unintended consequences, and policy.

12 Common mistakes when using Process Metrics

#1 – Being reactionless

If you collect metrics, you need to use them somehow. Therefore, one of the most common mistakes is doing nothing about the metrics you are seeing. Metrics can give you process improvement insights and, to react, you need to understand how they work and what they mean.

For more information on how to use them, check these blog posts:

• Cumulative Flow Diagrams
• Throughput and Burn-up Charts
• Lead Time

#2 – Using metrics with few data

Another mistake is to use metrics without enough data to support them. At the beginning of a project, or when you just started using metrics, we are often anxious to start gathering results from them. However, with a low amount of data, metrics aren’t that trustworthy. A good hint is seeing if they are still changing over time or if they are steadier… When the latter happens, you are probably ready to start analyzing them and act based on results. More on how to act can be found on our metrics blog posts.

Another hint would be to try daily metrics, check our blog post on them: Pros and cons of using daily metrics

#3 – Using metrics without considering their context

This is a very common mistake, not only in software development but with every statistically built conclusion. Numbers alone are used just for algebra or calculus. You need the context in which they are inserted to understand them. With that in mind, to say if your throughput is healthy or not, to understand if your lead time variance is big or not, look. at. the. context.

#4 – Comparing metrics between teams

This problem is related to number 3. It doesn’t make any sense to say something like “team A is doing better than team B because they have a greater throughput”. What if team A has 10 people and team B has 3? What if team A is working in an easy website development while team B is working with complex deep learning stuff? Be careful.

#5 – Having individual metrics

This is a micromanaging problem. People, when trying to improve as much as possible the process, end up measuring individual metrics. This problem is related to #3 and #4. You cannot compare different people. Just don’t. If you do it, you’ll be harming your team’s environment and will even decrease their productivity. Moreover, the process’ metrics should be used to understand the health of the process.

#6 – Simplifying metrics reading too much

Still related to context, but now the numbers context. If you tell other people that a team delivers on average 4 stories a week, you are saying nothing. Maybe its delivery data is {0, 0, 0, 0, 0, 24}, maybe is {4, 4, 4, 4, 4, 4}. So, be sure that you are not simplifying your metrics reading. Make sure the whole toolset builds the image that you are trying to draw.

#7 – Using only the metrics you want

Related to the error before, sometimes we see people having to report their metrics to higher management showing only “good numbers”. So, if your throughput increases, you only show your throughput increase. If your backlog decreases, you just show that. Be transparent. Otherwise, they will be living a lie and, when the truth comes up, you won’t be able to explain yourself.

#8 – Using only the data you want

Another related problem is using metrics with only the data you want. Cropping your data to get only relevant results, like in a 10-month project consider only the last 2 months, may make sense since the context of the project changes with time and you wanna make sure you are getting the right context in your results. However, be very careful when doing that because you may actually hide a lot of useful information from yourself.

#9 – “Cooking” metrics

This is by far the most common thing I see. People are afraid of showing bottlenecks or problems and end up masking their results. People group stories into one to diminish their backlog, break stories into more to increase their throughput or even change story points to keep their velocity. With that, you are only fooling yourself and not improving your process.

#10 – Having metrics-based goals

This is a controversial topic. Metrics weren’t made to be goals. They were created to help the team understand the process and try to improve its flow. Metrics-related goals may put too much pressure on the team and have the opposite effect on them, making one metric reach the desired goal but affecting others. Therefore, before defining a metric-based goal, consider if it needs to be that “low-level” and, if it does, confirm with the team if it is actually possible to reach that goal or if there’s some process inherent impediment to it.

#11 – Trying to decrease lead time at all costs

Lead time (LT) is a metric used to understand how long an item takes to pass through your process. So, there are two different questions you can ask the data:

• Is the LT too big?
• Is the LT variance too big?

The second is often much more important to a team than the first. Having an LT distribution of {0, 5, 2, 8} is usually worse than having one like {4, 4, 4, 4}. That because, in the first, your data is not reliable enough to make predictions, while in the second you have a better probability of getting it right. However, don’t forget to look at your context.

#12 – Trying to increase throughput instead of being more efficacious

Being efficacious is doing the right thing. Throughput is not important if you are not doing the right thing. So, focus on your product, on what is best for it, before caring about how fast you will deliver it.

Checklist Structure

Besides providing activities for implementing the quality management system, this tool also contains a functionality to verify correct completion of the activities: checklists. Go to the checklists via the menu bar.

The checklists can be constructed by the user him/herself to get checklists tailor-made to the extent of implementing the quality management system using a matrix.

Clicking on a Phase-button leads you to a checklist for that phase. Clicking on a QSE button leads you to the checklist for that QSE. Clicking on one of the buttons in the columns leads you to a checklist with questions related to activities in a Phase-QSE combination. See the figure below:

Below you see part of the checklist for the QSE Customer Focus in phase 3 (which you get when clicking on the button between the QSE Customer Focus and Phase 3). On the right-hand side links to the activities are given to which these checklist questions are related. If you have to answer a question negatively, you can click on the Activity-link and see what you need to do in order to get a positive answer to that question.

System configuration management

Whenever a software is build, there is always scope for improvement and those improvements brings changes in picture. Changes may be required to modify or update any existing solution or to create a new solution for a problem. Requirements keeps on changing on daily basis and so we need to keep on upgrading our systems based on the current requirements and needs to meet desired outputs. Changes should be analyzed before they are made to the existing system, recorded before they are implemented, reported to have details of before and after, and controlled in a manner that will improve quality and reduce error. This is where the need of System Configuration Management comes.

System Configuration Management (SCM) is an arrangement of exercises which controls change by recognizing the items for change, setting up connections between those things, making/characterizing instruments for overseeing diverse variants, controlling the changes being executed in the current framework, inspecting and revealing/reporting on the changes made. It is essential to control the changes in light of the fact that if the changes are not checked legitimately then they may wind up undermining a well-run programming. In this way, SCM is a fundamental piece of all project management activities.

Processes involved in SCM –
Configuration management provides a disciplined environment for smooth control of work products. It involves the following activities:

1.     Identification and Establishment – Identifying the configuration items from products that compose baselines at given points in time (a baseline is a set of mutually consistent Configuration Items, which has been formally reviewed and agreed upon, and serves as the basis of further development). Establishing relationship among items, creating a mechanism to manage multiple level of control and procedure for change management system.

2.     Version control – Creating versions/specifications of the existing product to build new products from the help of SCM system. A description of version is given below:

Suppose after some changes, the version of configuration object changes from 1.0 to 1.1. Minor corrections and changes result in versions 1.1.1 and 1.1.2, which is followed by a major update that is object 1.2. The development of object 1.0 continues through 1.3 and 1.4, but finally, a noteworthy change to the object results in a new evolutionary path, version 2.0. Both versions are currently supported.

3.     Change control – Controlling changes to Configuration items (CI). The change control process is explained in Figure below:

A change request (CR) is submitted and evaluated to assess technical merit, potential side effects, overall impact on other configuration objects and system functions, and the projected cost of the change. The results of the evaluation are presented as a change report, which is used by a change control board (CCB) —a person or group who makes a final decision on the status and priority of the change. An engineering change Request (ECR) is generated for each approved change.

Also CCB notifies the developer in case the change is rejected with proper reason. The ECR describes the change to be made, the constraints that must be respected, and the criteria for review and audit. The object to be changed is “checked out” of the project database, the change is made, and then the object is tested again. The object is then “checked in” to the database and appropriate version control mechanisms are used to create the next version of the software.

4.     Configuration auditing – A software configuration audit complements the formal technical review of the process and product. It focuses on the technical correctness of the configuration object that has been modified. The audit confirms the completeness, correctness and consistency of items in the SCM system and track action items from the audit to closure.

5.     Reporting – Providing accurate status and current configuration data to developers, tester, end users, customers and stakeholders through admin guides, user guides, FAQs, Release notes, Memos, Installation Guide, Configuration guide etc .

SCM Tools –

Different tools are available in market for SCM like: CFEngine, Bcfg2 server, Vagrant, SmartFrog, CLEAR CASETOOL (CC), SaltStack, CLEAR QUEST TOOL, Puppet, SVN- Subversion, Perforce, TortoiseSVN, IBM Rational team concert, IBM Configuration management version management, Razor, Ansible, etc. There are many more in the list.

It is recommended that before selecting any configuration management tool, have a proper understanding of the features and select the tool which best suits your project needs and be clear with the benefits and drawbacks of each before you choose one to use.

Metrics in software configuration management

Software configuration management (SCM) is a set of processes, policies, and tools that organizes the development process. It simultaneously maintains the current state of the software (called the “baseline”), while enabling developers to work on new versions for features or fixes.

Software Configuration Management Patterns

UNIT-II:

Risk Management

What is Risk Management?

Risk management is the process of identifying, assessing, and prioritizing the risks to minimize, monitor, and control the probability of unfortunate events.

Risk Management Process:

Risk Management process can be easily understood with use of the following workflow:

Risk Management Practices:

·        Software Risk Evaluation (SRE)

·        Continuous Risk Management (CRM)

·        Team Risk Management (TRM)

Project Risk Management

Managers can plan their strategy based on four steps of risk management which prevails in an organization. Following are the steps to manage risks effectively in an organization:

·        Risk Identification

·        Risk Quantification

·        Risk Response

·        Risk Monitoring and Control

What is Risk Management?

Risk management is simply the identification, assessment and prioritization of risks, followed by a coordinated and economical application of resources to minimize or control the probability of occurrence and the impact of negative events, as well as to maximize the realization of opportunities. What is considered a risk? Risks can come from uncertainty in financial markets, project failures, legal actions, regulatory liabilities, accidents, and natural disasters as well as simple human error. 

The definition of risk is generally compartmentalized based upon whether the risk is in the context of business continuity, project management, security, engineering, industrial processes, financial portfolios, actuarial assessments, or public health and safety. The potential list is finite, but is certainly overwhelming. Within the context of Reliability Excellence and effective continuous improvement, risk management can be limited to two major categories: business and asset risk.

Risk Management - Lifecycle

Risk Management - Lifecycle

The following diagram shows the flow of Risk Management life-cycle:

Risk identification

 is the process of determining risks that could potentially prevent the program, enterprise, or investment from achieving its objectives. It includes documenting and communicating the concern.

Risk quantification

 is a process to evaluate identified risks to produce data that can be used in deciding a response to corresponding risks. ... The process of risk quantification is an important step of the risk management process and therefore, important to ensuring the success of a project.

Risk Mitigation Planning, Implementation, and Progress Monitoring

Risk mitigation planning is the process of developing options and actions to enhance opportunities and reduce threats to project objectives [1]. Risk mitigation implementation is the process of executing risk mitigation actions. Risk mitigation progress monitoring includes tracking identified risks, identifying new risks, and evaluating risk process effectiveness throughout the project 

Software Requirements

The software requirements are description of features and functionalities of the target system. Requirements convey the expectations of users from the software product. The requirements can be obvious or hidden, known or unknown, expected or unexpected from client’s point of view.

Requirement Engineering

The process to gather the software requirements from client, analyze and document them is known as requirement engineering.

The goal of requirement engineering is to develop and maintain sophisticated and descriptive ‘System Requirements Specification’ document.

Requirement Engineering Process

It is a four step process, which includes –

• Feasibility Study
• Requirement Gathering
• Software Requirement Specification
• Software Requirement Validation

Let us see the process briefly -

Feasibility study

When the client approaches the organization for getting the desired product developed, it comes up with rough idea about what all functions the software must perform and which all features are expected from the software.

Referencing to this information, the analysts does a detailed study about whether the desired system and its functionality are feasible to develop.

This feasibility study is focused towards goal of the organization. This study analyzes whether the software product can be practically materialized in terms of implementation, contribution of project to organization, cost constraints and as per values and objectives of the organization. It explores technical aspects of the project and product such as usability, maintainability, productivity and integration ability.

The output of this phase should be a feasibility study report that should contain adequate comments and recommendations for management about whether or not the project should be undertaken.

Requirement Gathering

If the feasibility report is positive towards undertaking the project, next phase starts with gathering requirements from the user. Analysts and engineers communicate with the client and end-users to know their ideas on what the software should provide and which features they want the software to include.

Software Requirement Specification

SRS is a document created by system analyst after the requirements are collected from various stakeholders.

SRS defines how the intended software will interact with hardware, external interfaces, speed of operation, response time of system, portability of software across various platforms, maintainability, speed of recovery after crashing, Security, Quality, Limitations etc.

The requirements received from client are written in natural language. It is the responsibility of system analyst to document the requirements in technical language so that they can be comprehended and useful by the software development team.

SRS should come up with following features:

• User Requirements are expressed in natural language.
• Technical requirements are expressed in structured language, which is used inside the organization.
• Design description should be written in Pseudo code.
• Format of Forms and GUI screen prints.
• Conditional and mathematical notations for DFDs etc.

Software Requirement Validation

After requirement specifications are developed, the requirements mentioned in this document are validated. User might ask for illegal, impractical solution or experts may interpret the requirements incorrectly. This results in huge increase in cost if not nipped in the bud. Requirements can be checked against following conditions -

• If they can be practically implemented
• If they are valid and as per functionality and domain of software
• If there are any ambiguities
• If they are complete
• If they can be demonstrated

Requirement Elicitation Process

Requirement elicitation process can be depicted using the folloiwng diagram:

• Requirements gathering - The developers discuss with the client and end users and know their expectations from the software.
• Organizing Requirements - The developers prioritize and arrange the requirements in order of importance, urgency and convenience.

·        Negotiation & discussion - If requirements are ambiguous or there are some conflicts in requirements of various stakeholders, if they are, it is then negotiated and discussed with stakeholders. Requirements may then be prioritized and reasonably compromised.

The requirements come from various stakeholders. To remove the ambiguity and conflicts, they are discussed for clarity and correctness. Unrealistic requirements are compromised reasonably.

• Documentation - All formal & informal, functional and non-functional requirements are documented and made available for next phase processing.

Requirement Elicitation Techniques

Requirements Elicitation is the process to find out the requirements for an intended software system by communicating with client, end users, system users and others who have a stake in the software system development.

There are various ways to discover requirements

Interviews

Interviews are strong medium to collect requirements. Organization may conduct several types of interviews such as:

• Structured (closed) interviews, where every single information to gather is decided in advance, they follow pattern and matter of discussion firmly.
• Non-structured (open) interviews, where information to gather is not decided in advance, more flexible and less biased.
• Oral interviews
• Written interviews
• One-to-one interviews which are held between two persons across the table.
• Group interviews which are held between groups of participants. They help to uncover any missing requirement as numerous people are involved.

Surveys

Organization may conduct surveys among various stakeholders by querying about their expectation and requirements from the upcoming system.

Questionnaires

A document with pre-defined set of objective questions and respective options is handed over to all stakeholders to answer, which are collected and compiled.

A shortcoming of this technique is, if an option for some issue is not mentioned in the questionnaire, the issue might be left unattended.

Task analysis

Team of engineers and developers may analyze the operation for which the new system is required. If the client already has some software to perform certain operation, it is studied and requirements of proposed system are collected.

Domain Analysis

Every software falls into some domain category. The expert people in the domain can be a great help to analyze general and specific requirements.

Brainstorming

An informal debate is held among various stakeholders and all their inputs are recorded for further requirements analysis.

Prototyping

Prototyping is building user interface without adding detail functionality for user to interpret the features of intended software product. It helps giving better idea of requirements. If there is no software installed at client’s end for developer’s reference and the client is not aware of its own requirements, the developer creates a prototype based on initially mentioned requirements. The prototype is shown to the client and the feedback is noted. The client feedback serves as an input for requirement gathering.

Observation

Team of experts visit the client’s organization or workplace. They observe the actual working of the existing installed systems. They observe the workflow at client’s end and how execution problems are dealt. The team itself draws some conclusions which aid to form requirements expected from the software.

Software Requirements Characteristics

Gathering software requirements is the foundation of the entire software development project. Hence they must be clear, correct and well-defined.

A complete Software Requirement Specifications must be:

• Clear
• Correct
• Consistent
• Coherent
• Comprehensible
• Modifiable
• Verifiable
• Prioritized
• Unambiguous
• Traceable
• Credible source

Software Requirements

We should try to understand what sort of requirements may arise in the requirement elicitation phase and what kinds of requirements are expected from the software system.

Broadly software requirements should be categorized in two categories:

Functional Requirements

Requirements, which are related to functional aspect of software fall into this category.

They define functions and functionality within and from the software system.

EXAMPLES -

• Search option given to user to search from various invoices.
• User should be able to mail any report to management.
• Users can be divided into groups and groups can be given separate rights.
• Should comply business rules and administrative functions.
• Software is developed keeping downward compatibility intact.

Non-Functional Requirements

Requirements, which are not related to functional aspect of software, fall into this category. They are implicit or expected characteristics of software, which users make assumption of.

Non-functional requirements include -

• Security
• Logging
• Storage
• Configuration
• Performance
• Cost
• Interoperability
• Flexibility
• Disaster recovery
• Accessibility

Requirements are categorized logically as

• Must Have : Software cannot be said operational without them.
• Should have : Enhancing the functionality of software.
• Could have : Software can still properly function with these requirements.
• Wish list : These requirements do not map to any objectives of software.

While developing software, ‘Must have’ must be implemented, ‘Should have’ is a matter of debate with stakeholders and negation, whereas ‘could have’ and ‘wish list’ can be kept for software updates.

User Interface requirements

UI is an important part of any software or hardware or hybrid system. A software is widely accepted if it is -

• easy to operate
• quick in response
• effectively handling operational errors
• providing simple yet consistent user interface

User acceptance majorly depends upon how user can use the software. UI is the only way for users to perceive the system. A well performing software system must also be equipped with attractive, clear, consistent and responsive user interface. Otherwise the functionalities of software system can not be used in convenient way. A system is said be good if it provides means to use it efficiently. User interface requirements are briefly mentioned below -

• Content presentation
• Easy Navigation
• Simple interface
• Responsive
• Consistent UI elements
• Feedback mechanism
• Default settings
• Purposeful layout
• Strategical use of color and texture.
• Provide help information
• User centric approach
• Group based view settings.

Software System Analyst

System analyst in an IT organization is a person, who analyzes the requirement of proposed system and ensures that requirements are conceived and documented properly & correctly. Role of an analyst starts during Software Analysis Phase of SDLC. It is the responsibility of analyst to make sure that the developed software meets the requirements of the client.

System Analysts have the following responsibilities:

• Analyzing and understanding requirements of intended software
• Understanding how the project will contribute in the organization objectives
• Identify sources of requirement
• Validation of requirement
• Develop and implement requirement management plan
• Documentation of business, technical, process and product requirements
• Coordination with clients to prioritize requirements and remove and ambiguity
• Finalizing acceptance criteria with client and other stakeholders

Software Metrics and Measures

Software Measures can be understood as a process of quantifying and symbolizing various attributes and aspects of software.

Software Metrics provide measures for various aspects of software process and software product.

Software measures are fundamental requirement of software engineering. They not only help to control the software development process but also aid to keep quality of ultimate product excellent.

According to Tom DeMarco, a (Software Engineer), “You cannot control what you cannot measure.” By his saying, it is very clear how important software measures are.

Let us see some software metrics:

·        Size Metrics - LOC (Lines of Code), mostly calculated in thousands of delivered source code lines, denoted as KLOC.

Function Point Count is measure of the functionality provided by the software. Function Point count defines the size of functional aspect of software.

• Complexity Metrics - McCabe’s Cyclomatic complexity quantifies the upper bound of the number of independent paths in a program, which is perceived as complexity of the program or its modules. It is represented in terms of graph theory concepts by using control flow graph.

·        Quality Metrics - Defects, their types and causes, consequence, intensity of severity and their implications define the quality of product.

The number of defects found in development process and number of defects reported by the client after the product is installed or delivered at client-end, define quality of product.

• Process Metrics - In various phases of SDLC, the methods and tools used, the company standards and the performance of development are software process metrics.
• Resource Metrics - Effort, time and various resources used, represents metrics for resource measurement.

·         ·         6 Effects of the Internet of Things on Project Management

At least six things will change, which will require project managers to adapt both technically and systematically.

1. IoT enables hyperspeed reporting

IoT substantially reduces the cost of communication.

The hyperconnected devices and constant flow of data that automate systems will speed things up considerably. No more idle times are required in between activities. No more silos from support systems such as databases, storage, and IT operations.

 IMPACT  Say you’re an IT project manager, and you need to run a status report on all of your organization’s desktop and laptop computers and tablets and mobile devices. In the past, this process might take weeks. But with the IoT, a project manager could run a report on the quantity and condition of all of those pieces in an instant.

2. IoT allows complete monitoring and process control

IoT allows project managers, management, and stakeholders to monitor and control activities in real time. The overall snapshot of a comprehensive system is monitored on a single screen, which allows overseers to immediately attend to any interruptions.

 IMPACT  Using equipment as an example, sensors will be used for monitoring and predicting maintenance needs throughout a project’s lifetime. The scope of devices, activities, and conditions that need to be tested will increase exponentially as projects become more complex. Ease of use and environments suddenly become critical.

3. IoT creates an explosion of valuable project data

In the past, archiving historical data was a time- and labor-intensive process. With the IoT, historical data will become available immediately, which is extremely helpful for current and future projects.

Everything from budgeting to individual meetings with team members will be recorded in great detail, providing a solid foundation for future decisions.

 IMPACT  Project management tools will need to be more responsive and scalable to accommodate this data explosion. Organizations need to make sure that their project management software package is capable of growing to accommodate this incoming flood of data. They also need to know when it’s time to upgrade—for example, if your team is capping out on your storage allowance each month.

4. IoT allows super-deep data analytics

With the IoT comes advanced data analytics, and advanced data analytics require advanced interpretations and management.

 IMPACT  Project managers must upgrade their skills related to data handling, which could mean increasing spend and resources toward data management, hiring experienced data analysts, and accounting for data analysis when creating the project timeline.

In other words, the more familiar project managers are with the importance of advanced data analysis, the better the chances for project success.

5. IoT ushers in stricter ethical and legal implications

Today’s internet-connected devices send data to each other extremely fast. We’re not dealing with dial-up modems anymore. One error could create a domino effect that could topple an entire project or, in extreme cases, an entire career before you can say “Enron.”

 IMPACT  Businesses of all sizes need to impose stricter ethical and legal implications on any slight mistake or oversight. Project managers and team members should be aware of this early on so that the project can be completed with minimal ethical and legal risks.

6. IoT raises expectations for all stakeholders

Once companies adopt IoT, the marketplace will be transformed into a level playing field. Only the strongest and the fittest will survive. No longer can organizations hide behind old excuses such as, “We don’t have access to that data” or, “We need a few weeks to get that report back.”

 IMPACT  Project managers need to lead the charge when it comes to raising standards in the IoT era. As a project manager, your job is to be aware of the most useful technology available and enable your team to use it.

Are you ready for the IoT revolution?

The IoT will change how we interact, how we work, and how we push ourselves to survive in business. In fact, this transformation has already begun.

IoT will level out the overall competition, leaving those who continuously upgrade our project management skills, both technical and soft, to thrive.

As a project manager, here are some key takeaways you can use to be ready:

• Read up on the IoT so that you can talk to your team about it.
• Consult your IT department to determine the extent of connected devices already in use on your network.
• Set up automatic reports leveraging IoT data.
• Look into upgrading your project management software so that it’s ready for the influx of data from the IoT.
• Beef up your data analysis knowledge and look into adding full-time data analysts to your team.
• Do a cybersecurity audit and make sure your data protection is airtight.

The IoT may seem futuristic now, but decades from now it could be as ubiquitous as the internet itself.

What is Capability Maturity Model?

The Software Engineering Institute (SEI) Capability Maturity Model (CMM) specifies an increasing series of levels of a software development organization. The higher the level, the better the software development process, hence reaching each level is an expensive and time-consuming process.

Levels of CMM

·        Level One :Initial - The software process is characterized as inconsistent, and occasionally even chaotic. Defined processes and standard practices that exist are abandoned during a crisis. Success of the organization majorly depends on an individual effort, talent, and heroics. The heroes eventually move on to other organizations taking their wealth of knowledge or lessons learnt with them.

·        Level Two: Repeatable - This level of Software Development Organization has a basic and consistent project management processes to track cost, schedule, and functionality. The process is in place to repeat the earlier successes on projects with similar applications. Program management is a key characteristic of a level two organization.

·        Level Three: Defined - The software process for both management and engineering activities are documented, standardized, and integrated into a standard software process for the entire organization and all projects across the organization use an approved, tailored version of the organization's standard software process for developing,testing and maintaining the application.

·        Level Four: Managed - Management can effectively control the software development effort using precise measurements. At this level, organization set a quantitative quality goal for both software process and software maintenance. At this maturity level, the performance of processes is controlled using statistical and other quantitative techniques, and is quantitatively predictable.

·        Level Five: Optimizing - The Key characteristic of this level is focusing on continually improving process performance through both incremental and innovative technological improvements. At this level, changes to the process are to improve the process performance and at the same time maintaining statistical probability to achieve the established quantitative process-improvement objectives.

Organizational Behavior - Models

Organizational behavior reflects the behavior of the people and management all together, it is considered as field study not just a discipline. A discipline is an accepted science that is based upon theoretical foundation, whereas OB is an inter-disciplinary approach where knowledge from different disciplines like psychology, sociology, anthropology, etc. are included. It is used to solve organizational problems, especially those related to human beings.

There are four different types of models in OB. We will throw some light on each of these four models.

Autocratic Model

The root level of this model is power with a managerial orientation of authority. The employees in this model are oriented towards obedience and discipline. They are dependent on their boss. The employee requirement that is met is subsistence. The performance result is less.

The major drawbacks of this model are people are easily frustrated, insecurity, dependency on the superiors, minimum performance because of minimum wage.

Custodial Model

The root level of this model is economic resources with a managerial orientation of money. The employees in this model are oriented towards security and benefits provided to them. They are dependent on the organization. The employee requirement that is met is security.

This model is adapted by firms having high resources as the name suggest. It is dependent on economic resources. This approach directs to depend on firm rather than on manager or boss. They give passive cooperation as they are satisfied but not strongly encouraged.

Supportive Model

The root level of this model is leadership with a managerial orientation of support. The employees in this model are oriented towards their job performance and participation. The employee requirement that is met is status and recognition. The performance result is awakened drives.

This model is dependent on leadership strive. It gives a climate to help employees grow and accomplish the job in the interest of the organization. Management job is to assist the employee’s job performance. Employees feel a sense of participation.

Collegial Model

The root level of this model is partnership with a managerial orientation of teamwork. The employees in this model are oriented towards responsible behavior and self-discipline. The employee requirement that is met is self-actualization. The performance result is moderate zeal.

This is an extension of supportive model. The team work approach is adapted for this model. Self-discipline is maintained. Workers feel an obligation to uphold quality standard for the better image of the company. A sense of “accept” and “respect” is seen.

Successful CRM is about competing in the relationship dimension. Not as an alternative to having a competitive product or reasonable price, but as a differentiator. If your competitors are doing the same thing as you are (as they generally are), product and price won’t give you a long-term, sustainable competitive advantage. But if you can get an edge based on how customers feel about your company, it’s a much stickier–sustainable–relationship over the long haul.”

− Bob Thompson, CustomerThink Corporation

Business people started using the term Customer Relationship Management (CRM) since the early 1990s when the concept of business started to change from being transactional to relational. CRM directly contributes towards customer benefits and the growth of businesses.

Information Technology plays a very critical role in identifying, acquiring, and retaining the customers, and thereby managing a healthy relationship with them.

Here in this chapter, we will discuss the very basics of CRM.

What is CRM?

There can be multiple definitions of CRM from different perspectives −

• From the viewpoint of the Management, CRM can be defined as an organized approach of developing, managing, and maintaining a profitable relationship with customers.
• By equating the term with technology, the IT organizations define CRM as a software that assists marketing, merchandising, selling, and smooth service operations of a business.
• As per Franics Buttle, World’s first professor of CRM, it is the core business strategy that integrates internal processes and functions, and external networks, to create and deliver value to a target customer at profit. It is grounded on high quality customer data and information technology.

The primary goal of CRM is to increase customer loyalty and in turn improve business profitability.

Ingredients of CRM

Take a look at the following illustration. It shows the ingredients that work together to form a successful CRM system.

Here are some of the important ingredients of CRM −

• Analytics − Analytics is the process of studying, handling, and representing data in various graphical formats such as charts, tables, trends, etc., in order to observe market trends.
• Business Reporting − Business Reporting includes accurate reports of sales, customer care, and marketing.
• Customer Service − Customer Service involves collecting and sending the following customer-related information to the concerned department −
  • Personal information such as name, address, age
  • Previous purchase patterns.
  • Requirements and preferences.
  • Complaints and suggestions.
• Human Resource Management − Human Resource Management involves employing and placing the most eligible human resource at a required place in the business.
• Lead Management − Lead Management involves keeping a track of the sales leads and distribution, managing the campaigns, designing customized forms, finalizing the mailing lists, and studying the purchase patterns of the customers.
• Marketing − Marketing involves forming and implementing sales strategies by studying existing and potential customers in order to sell the product.
• Sales Force Automation − Sales Force Automation includes forecasting, recording sales, processing, and keeping a track of the potential interactions.
• Workflow Automation − Workflow Automation involves streamlining and scheduling various processes that run in parallel. It reduces costs and time, and prevents assigning the same task to multiple employees.

Objectives of CRM

The most prominent objectives of using the methods of Customer Relationship Management are as follows −

• Improve Customer Satisfaction − CRM helps in customer satisfaction as the satisfied customers remain loyal to the business and spread good word-of-mouth. This can be accomplished by fostering customer engagement via social networking sites, surveys, interactive blogs, and various mobile platforms.
• Expand the Customer Base − CRM not only manages the existing customers but also creates knowledge for prospective customers who are yet to convert. It helps creating and managing a huge customer base that fosters profits continuity, even for a seasonal business.
• Enhance Business Sales − CRM methods can be used to close more deals, increase sales, improve forecast accuracy, and suggestion selling. CRM helps to create new sales opportunities and thus helps in increasing business revenue.
• Improve Workforce Productivity − A CRM system can create organized manners of working for sales and sales management staff of a business. The sales staff can view customer’s contact information, follow up via email or social media, manage tasks, and track the salesperson’s performance. The salespersons can address the customer inquiries speedily and resolve their problems.

History of CRM