🚧Project Management: Risk assessment (Definitions)

"Describes risks under the initial project plan and may indicate areas of needed risk management." (Timothy J  Kloppenborg et al, "Project Leadership", 2003)

"A process to identify potential situations that could cause change to an effort from both internal and external forces, assign severity and priority ranks in order to determine overall risk, managing a situation or project to mitigate or minimize the occurrence of risk, and if the risk materializes, to minimize loss or damage." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

[Qualitative risk assessment:] "Mostly entirely subjective and therefore less accurate than quantitative risk assessments. However, their benefit is that they are much quicker to produce than the quantitative kind" (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

[Qualitative risk assessments:] "these are subjective in nature, and are generally expressed in verbal terms such as ‘high’, ‘medium’ and ‘low’. This is not an ideal state of affairs, as it renders risk assessments unreliable, and should be grounded in more rigorously." (David Sutton, "Information Risk Management: A practitioner’s guide", 2014)

"An analysis of threats and vulnerabilities against assets. A risk assessment allows the risks to be prioritized." (Weiss, "Auditing IT Infrastructures for Compliance" 2nd Ed., 2015)

"A process used to quantitatively or qualitatively determine the risk associated with an actual or hypothesized system." (O Sami Saydjari, "Engineering Trustworthy Systems: Get Cybersecurity Design Right the First Time", 2018)

"The overall process of risk identification, risk analysis, and risk evaluation." (William Stallings, "Effective Cybersecurity: A Guide to Using Best Practices and Standards", 2018)

"'analyze assets’ value, identify threats and evaluate their vulnerability to those threats" (ITIL)

"the overall process of risk identification, risk analysis and risk evaluation" (ISO Guide 73:2009) 

"The process of identifying and subsequently analyzing the identified project or product risk to determine its level of risk, typically by assigning likelihood and impact ratings."  (ISTQB)

🧭Business Intelligence: Enterprise Reporting (Part XI: Between Products, Partners, People and Processes)

Business Intelligence Series

In the previous post, “BI between Potential, Reality, Quality and Stories”, I was commenting five of the important findings of a study led by KPMG in respect to the state of art in BI initiatives. My comments were centered mainly on the first 3 of the 4Ps (Products, People, Partners, respectively Processes) considered in ITSM (IT Service Management). The connection to IT Service Management isn’t accidental, BI being also an organizational capability. Many of the aspects related to the 4Ps perspectives, reveal the maturity of an organization in leveraging its BI infrastructure.  In this post I would like to consider BI landscape from these 4 perspectives.

Products

Products or technology perspective has within BI context a dual nature. First of all we have to consider the BI infrastructure – the whole set of BI tools we have at disposal for our shiny reports. Secondly, because the BI infrastructure doesn’t stand on itself, we have to consider also IT infrastructure on which BI infrastructure is based upon – a full range of ISs (Information Systems) in which data are entered, processed, transported and consumed before they are used by the BI tools. For Data Quality issues, we often have to consider the broader perspective, and tackle the problems at the source. Otherwise we might arrive to treat the symptoms and not the causes. It’s important to note that the two layers or perspectives are interconnected, the consequences being bidirectional.

A typical BI infrastructure revolves around several databases, maybe one or more data warehouses and data marts, and one or more reporting systems. Within the most basic scenario, the data flow is unidirectional from databases to data warehouse/marts, reports being built on top of the data warehouse/marts or directly on the IS’ databases. In more complex scenarios, the data can flow between the various ISs when they were integrated, and even between data warehouses/marts, within a unidirectional or bidirectional flow.  Unless the reports are based directly on the ISs’ databases, such architectures lead to data duplication, conversions between complex schemas, delays between the various layers, to mention just a few of the most important implications. In some point in time the complexity falls down on you.

One of the problems I met is that a considerable percent of the IS are not developed to address BI requirements. It starts with data validation, with the way data are modeled, structured, formatted and made available for BI consumption. If you want to increase the quality of your data, you have sooner or later to address them. It’s important thus the degree to which the systems are designed to cover the BI needs in particular, and decision making in general. This presumes that BI requirements need to be addressed in early phases of implementations, software design or when tools are consider for purchase.

In addition many ISs come with their own (standard) reports or reporting frameworks, becoming thus part of your BI infrastructure, intended or unintended. Even if such reports are intended to cover basic immediate reporting requirements, they not always so easy to consume, the logic behind them is not visible, are hard to extend, are not always tested, the additional reports built in other tools need to be synchronized with them, etc.

Partners

We gather huge volumes of data, we are drowning in it; we want to take decision rooted in data and get visibility into the past, actual and future state of business. How can we achieve that if we don’t have the knowledge and human resources to achieve that? “Partners” is the magic word – external suppliers specialized, in theory, to provide this kind of services: BI analysts and developers, business analysts, data miners, and other IT professionals work together in order to build your BI infrastructure. One detail many people forget is that BI tools provide potentiality; are the skills and knowledge of those working with them that transforms that potentiality into success. On their capabilities depends the success of such projects. Not to forget that BI projects are similar to other IT projects, falling under same type of fallacies plus a few other fallacies of their own derived from exploratory and complex nature of BI projects.

There is a dual nature also in “partners” perspective – except the external perspective which concerns the external partners and the IT department or the business as a whole, there is also the internal perspective in which the IT department plays again a central role. I heard it often loudly affirmed that the other departments are customers of the IT department, or the reciprocal. I have seen also this conception brought to extreme, in which the IT had no word to say in what concerns the IT infrastructure in general, respectively the BI infrastructure in particular. As long the IT department isn’t treated as a business partner, an organization will be more likely sabotaged from inside. Sabotage it’s a word too strong maybe, though it kind of reflects the state of art.

People

Same as partners, people perspective includes a considerable variety of types: IT staff, executives, managers, end-users and other types of stakeholders, each of them with a word to say, grouped in various groups of interests that don’t always converge, situations in which politics plays a major role. It’s actually interesting to see how the decision for a given BI solution is made, how the solution takes its place into the landscape, how it’s used and misused, how personalities and knowledge harness it or stand in the way. I feel that there are organizations (people) which do BI just for the sake of doing something, copying sometimes recipes of success, without uniting the dots, without clear goals and strategy. There are people who juggle with numbers and BI concepts without knowing their meaning and what they involve. This aspect is reflected in how BI tools are selected, implemented and used.

Having the best tools, consultants and highest data quality, won’t guarantee the success of BI initiative without users’ acceptance, without teaching them how to make constructive use of tools and data, on how to use and built models in order to solve the problems the business is confronted with, on how to address strategic, tactical and operational requirements. The transformation from a robot to a knowledge worker doesn’t happen over night. Is needed to make people aware of the various aspects of BI – data quality, process and data ownership, on how models can be used and misused, on how models evolve or become obsolete, how the BI infrastructure has to evolve with the business’ dynamics. There are so many aspects that need to be considered. It’s a continuous learning process.

Processes

In processes' perspective can be depicted a dual nature too. First of all we have to consider the processes which are used to manage efficiently and effectively the whole BI infrastructure. They are widely discussed in various methodologies like ITIL, whose implementation is thoroughly documented. Secondly, it’s the reflection of departmental processes within the various data perspectives – how they are measured, and how the measurements are further used for continuous improvement. 

Considering that this aspect is correlated with an organization’s capability model, I don’t think that many organizations go/rich that far. Sure the trend is to define meaningful KPIs, growth, health and other type of metrics, but the question is – are you using those metrics constructively, are you aligning them with your strategic, tactic and operational goals? I think there is lot of potential in this, though in order to measure processes accordingly is imperative to have also the system designed for this purpose. Back to technological perspective…

 

Previous Post <<||>> Next Post

🚧Project Management: Project Risk (Definitions)

"An undesirable event which, if it occurs, can jeopardize the success of the project. These risks may affect cost or schedule." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"A quantitative measure of the possibility of an accident, the product of the likelihood of the accident and its severity; in project management, an unwelcome impact on cost, effort, functionality, or schedule." (Bruce P Douglass, "Real-Time Agility", 2009)

"Threats to the management of equipment, finances, resources, technology, time frames, and people associated with specific projects." (Annetta Cortez & Bob Yehling, "The Complete Idiot's Guide To Risk Management", 2010)

"A risk related to management and control of the project." (Requirements Engineering Qualifications Board, "Standard glossary of terms used in Requirements Engineering", 2011)

"An uncertain event or condition that, if it occurs, has a positive or negative effect on a project's objectives." (Cynthia Stackpole, "PMP Certification All-in-One For Dummies", 2011) 

"Refers to the possibility of occurrence of an event, whether uncertain or of undetermined term, which is not entirely under the control of the people involved and is contrary to their expectations or interest. Risk can be voluntary, when a person acts despite being aware of that possibility." (Humbert Lesca & Nicolas Lesca, "Weak Signals for Strategic Intelligence: Anticipation Tool for Managers", 2011)

"Project risk is uncertainty that can affect outcomes. Risk can introduce a positive (opportunity) or negative (threat) change." (Mike Clayton, "Brilliant Project Leader", 2012)

"In the context of business decisions, the cost of a particular outcome. When a set of outcomes are possible, this cost is often weighted by the probability, if known, of that particular outcome occurring. Not to be confused with uncertainty, a term often used incorrectly to communicate the level of risk." (Kenneth A Shaw, "Integrated Management of Processes and Information", 2013)

"Combination of the probability or frequency of occurrence of a defined threat or opportunity and the magnitude of the consequences of the occurrence." (Chartered Institute of Building, "Code of Practice for Project Management for Construction and Development" 5th Ed., 2014)

"An uncertain event that, if it occurs, has a positive or negative effect on one or more objectives." (Paul H Barshop, "Capital Projects", 2016)

"The chance of a negative thing happening." (Pamela Schure & Brian Lawley, "Product Management For Dummies", 2017)

🧭Business Intelligence: Enterprise Reporting (Part X: Between Potential, Reality, Quality and Stories)

Business Intelligence Series

Have you ever felt that you are investing quite a lot of time, effort, money and other resources into your BI infrastructure, and in the end you don’t meet your expectations? As it seems you’re not the only one. The “Does your business intelligence tell you the whole story” paper released in 2009 by KPMG provides some interesting numbers to support that:

1. “More than 50% of business intelligence projects fail to deliver the expected benefit” (BI projects failure)
2. “Two thirds of executives feel that the quality of and timely access to data is poor and inconsistent” (reports and data quality)
3. “Seven out of ten executives do not get the right information to make business decisions.” (BI value)
4. “Fewer than 10% of organizations have successfully used business intelligence to enhance their organizational and technological infrastructures”  (BI alignment)
5. “those with effective business intelligence outperform the market by more than 5% in terms of return on equity” (competitive advantage)

The numbers reflect to some degree also my expectations, though they seem more pessimistic than I expected. That’s not a surprise, considering that such studies can be strongly biased, especially because in them are reflected expectations, presumptions and personal views over the state of art within an organization.

KPMG builds on the above numbers and several other aspects that revolve around the use of governance and alignment in order to increase the value provided by BI to the business, though I feel that they are hardly scratching the surface. Governance and alignment look great into studies and academic work, though they alone can’t bring success, no matter how much their importance and usage is accentuated. Sometimes I feel that people hide behind big words without even grasping the facts. The importance of governance and alignment can’t be neglected, though the argumentation provided by KPMG isn’t flawless. There are statements I can agree with, and many which are circumstantial. Anyway, let’s look a little deeper at the above numbers.

I suppose there is no surprise concerning the huge rate of BI projects’ failure. The value is somewhat close to the rate of software projects’ failure. Why would make a BI project an exception from a typical software project, considering that they are facing almost the same environments and challenges?  In fact, given the role played by BI in decision making, I would say that BI projects are more sensitive to the various factors than a typical software project.  

It doesn’t make sense to retake the motives for which software projects fail, but some particular aspects need to be mentioned. KPMG insists on the poor quality of data, on the relevance and volume of reports and metrics used, the lack of reflecting organization’s objectives, the inflexibility of data models, lack of standardization, all of them reflecting in a degree or other on the success of a BI project. There is much more to it!

KPMG refers to a holistic approach concentrated on the change of focus from technology to the actual needs, a change of process and funding.  A reflection of the holistic approach is also the view of the BI infrastructure from the point of view of the entire IT infrastructure, of the organization, network of partners and of the end-products – mainly models and reports. Many of the problems BI initiatives are confronted with refer to the quality of data and its many dimensions (duplicates, conformity, consistency, integrity, accuracy, availability, timeliness, etc.) , problems which could be in theory solved in the source systems, mainly through design. Other problems, like dealing with complex infrastructures based on more or less compatible IS or BI tools, might involve virtualization, consolidation or harmonization of such solutions, plus the addition of other tools.

Looking at the whole organization, other problems appear: the use of reports and models without understanding the whole luggage of meaning hiding behind them, the different views within the same data and models, the difference of language, problems, requirements and objectives, the departmental and organizational politics, the lack of communication, the lack of trust in the existing models and reports, and so on. What all these points have in common are people! The people are the maybe the most important factor in the adoption and effective usage of BI solutions. It starts with them – identifying their needs, and it ends with them – as end users. Making them aware of all contextual requirements, actually making them knowledge workers and not considering them just simple machines could give a boost to your BI strategy.

Partners doesn’t encompass just software vendors, service providers or consultants, but also the internal organizational structures – teams, departments, sites or any other similar structure. Many problems in BI can be tracked down to partners and the ways a partnership is understood, on how resources are managed, how different goals and strategies are harmonized, on how people collaborate and coordinate. Maybe the most problematic is the partnership between IT and the other departments on one side, and between IT and external partners on the other side. As long IT is not seen as a partner, as long IT is skip from the important decisions or isn’t acting as a mediator between its internal and external partners, there are few chances of succeeding. There are so many aspects and lot of material written on this topic, there are models and methodologies supposed to make things work, but often between theory and practice there is a long distance.

How many of the people you met were blaming the poor quality of the data without actually doing something to improve anything? If the quality of your data in one of your major problems then why aren’t you doing something to improve that?  Taking the ownership over your data is a major step on the way to better data quality, though a data management strategy is needed. This involve the design of a framework that facilitates data quality and data consumption, the design and use of policies, practices and procedures to properly manage the full data lifecycle. Also this can be considered as part of your BI infrastructure, and given the huge volume, the complexity and diversity of data, is nowadays a must for an organization.

The “right information” is an evasive construct. In order to get the right information you must be capable to define what you want, to design your infrastructure with that in mind and to learn how to harness your data. You don’t have to look only at your data and information but also at the whole DIKW pyramid. The bottom line is that you don’t have to build only a BI infrastructure but a knowledge management infrastructure, and methodologies like ITIL can help you achieve that, though they are not sufficient. Sooner or later you’ll arrive to blame the whole DIKW pyramid - the difficulty of extracting information from data, knowledge from information, and the ultimate translation into wisdom. Actually that’s also what the third and fourth of the above statements are screaming out loud – it’s not so easy to get information from the silos of data, same as it’s not easy to align the transformation process with organizations’ strategy.

Also timeliness has a relative meaning. It’s true that nowadays’ business dynamics requires faster access to data, though it requires also to be proactive, many organizations lacking this level of maturity. In order to be proactive it’s necessary to understand your business’ dynamics thoroughly, that being routed primarily in your data, in the tools you are using and the skill set your employees acquired in order to move between the DIKW layers. I would say that the understanding of DIKW is essential in harnessing your BI infrastructure.

KPMG considers that the 5% increase in return on equity associated with the effective usage of BI is a positive sign, not necessarily. The increase can be associated with hazard or other factors as well, even if it’s unlikely probable to be so. The increase it’s quite small when considered with the huge amount of resources spent on BI infrastructure. I believe that BI can do much more for organizations when harnessed adequately. It’s just a belief that needs to be backed up by numbers, hopefully that will happen someday, soon.

Previous Post <<||>> Next Post

🚧Project Management: Cost Performance Index (Definitions)

"A measure of cost efficiency on a project. It is the ratio of earned value (EV) to actual costs (AC). CPI = EV divided by AC. " (Cynthia Stackpole, "PMP® Certification All-in-One For Dummies®", 2011)

"The ratio of budgeted costs to actual costs (BCWP/ACWP). To forecast the cost at completion, multiply the original cost baseline by CPI." (Bonnie Biafore, "Successful Project Management: Applying Best Practices and Real-World Techniques with Microsoft® Project", 2011)

"The ratio of earned value to actual cost, indicating how close the planned cost for completed work is to the actual cost. A CPI greater than 1 means the project is under budget. A CPI less than 1 means the project is over budget." (Bonnie Biafore & Teresa Stover, "Your Project Management Coach: Best Practices for Managing Projects in the Real World", 2012)

"A measure of the cost efficiency of budgeted resources expressed as the ratio of earned value to actual cost." (For Dummies, "PMP Certification All-in-One For Dummies" 2nd Ed., 2013)

"The ratio of Earned Value of an activity to its Actual Cost. CPI = BCWP/ACWP or CPI = EV/AC." (Christopher Carson et al, "CPM Scheduling for Construction: Best Practices and Guidelines", 2014)

"A measure of cost efficiency on a project. It is the ratio of earned value (EV) to actual costs (AC). CPI=EV divided by AC." (Jeffrey K Pinto, "Project Management: Achieving Competitive Advantage 5th Ed.", 2018)

"Ratio of earned value to actual cost to measure efficiency of budgeted resources." (Cate McCoy & James L Haner, "CAPM Certified Associate in Project Management Practice Exams", 2018)

"A measure of the cost efficiency of budgeted resources expressed as the ratio of earned value to actual cost. See also schedule performance index (SPI)." (Project Management Institute, "Practice Standard for Scheduling" 3rd Ed., 2019)

🚧Project Management: RACI Matrix

"A two-dimensional table that lists tasks or deliverables as the row headings, and roles (or people’s names) as the column headings. The cell data contains the responsibility by task and by role (or person): R = Responsible; A = Accountable; C = Consulted; I = Informed." (Clyde M Creveling, "Six Sigma for Technical Processes: An Overview for R Executives, Technical Leaders, and Engineering Managers", 2006)

"A matrix used to describe classes of involved parties and their impact on a situation by role." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A table used to document tasks and the personnel responsible for the assignments. RACI stands for responsible, accountable, consulted, and informed." (Weiss, "Auditing IT Infrastructures for Compliance" 2nd Ed., 2015)

"A matrix describing the participation by various roles in completing tasks or deliverables for a project or process. It is especially useful in clarifying roles and responsibilities. RACI is an acronym derived from the four key responsibilities most typically used: Responsible, Accountable, Consulted, and Informed." (ISTQB)

🚧Project Management: Schedule (Definitions)

"The planned dates for performing activities and the planned dates for meeting milestones." (Timothy J  Kloppenborg et al, "Project Leadership", 2003)

"(1) A document showing the tasks for a project and specific calendar dates when each task will be started and completed. (2) The total time elapsed to build a product (calendar days)." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"The set of project milestones and their planned dates of accomplishment. The actual dates of accomplishment are also usually recorded as the project proceeds." (Richard D Stutzke, "Estimating Software-Intensive Systems: Projects, Products, and Processes", 2005)

"The schedule contains all the activities that need to be performed, including their sequence and interdependencies, milestones, duration, estimated effort, start and end dates, as well as resource assignment. In addition, it should detail the critical path or paths." (Lars Dittmann et al, "Automotive SPICE in Practice", 2008)

"An ordered set of tasks characterized by duration and loading onto resources. For project management, this is the plan that specifies which people should perform what tasks when. For a concurrent system, this is a statement of what tasks should be executed by the scheduler and when." (Bruce P Douglass, "Real-Time Agility", 2009)

"The planned dates for performing schedule activities and the planned dates for meeting schedule milestones." (Project Management Institute, "Practice Standard for Project Estimating", 2010)

"The overall timeline for a project including task dates, durations, relationships, costs, and resource assignments." (Bonnie Biafore, "Successful Project Management: Applying Best Practices and Real-World Techniques with Microsoft Project", 2011)

"The planned dates for performing schedule activities and the planned dates for meeting schedule milestones." (Cynthia Stackpole, "PMP® Certification All-in-One For Dummies", 2011)

"An output of a schedule model that presents linked activities with planned dates, durations, milestones, and resources." (For Dummies, "PMP Certification All-in-One For Dummies" 2nd Ed., 2013)

"A listing of project tasks, subtasks, and estimated completion times." (Robert F Smallwood, "Information Governance: Concepts, Strategies, and Best Practices", 2014)

"Time plan for a project or process. Note: on a construction project this is usually referred to as a 'project programme'. The construction industry tends to refer to programmes rather than schedules. Indeed the term schedule tends to mean a schedule of items in tabular form, e.g. door schedule, ironmongery schedule, etc." (Chartered Institute of Building, "Code of Practice for Project Management for Construction and Development" 5th Ed., 2014)

🚧Project Management: Fast-Tracking (Definitions)

"A schedule compression technique in which activities or phases normally done in sequence are performed in parallel for at least a portion of their duration." (For Dummies, "PMP Certification All-in-One For Dummies" 2nd Ed., 2013)

"A specific project schedule compression technique that changes network logic to overlap phases that would normally be done in sequence, such as the design phase and construction phase, or to perform schedule activities in parallel." (Cynthia Stackpole, "PMP® Certification All-in-One For Dummies", 2011)

"Shortening the duration of a project by overlapping tasks that would normally be run sequentially, such as design and construction." (Bonnie Biafore, "Successful Project Management: Applying Best Practices and Real-World Techniques with Microsoft Project", 2011)

"The technique for shortening the schedule in which adjustments are made where possible to overlap tasks, execute tasks in parallel rather than in sequence, or shorten lag time." (Bonnie Biafore & Teresa Stover, "Your Project Management Coach: Best Practices for Managing Projects in the Real World", 2012)

"A specific project schedule compression technique that changes network logic to overlap phases that would normally be done in sequence, such as the design phase and construction phase, or to perform schedule activities in parallel. See also crashing and schedule compression." (Jeffrey K Pinto, "Project Management: Achieving Competitive Advantage" 5th Ed., 2018)

"Starting the construction process on a project while design is still underway (i.e., overlapping design and construction of a project)." (Peter Oakander et al, "CPM Scheduling for Construction: Best Practices and Guidelines", 2014)

🚧Project Management: Backlog (Definitions)

"A prioritized list of project requirements with estimated times to turn them into completed product functionality. Estimates are in days and are more precise the higher an item is in the Product Backlog priority. The list evolves, changing as business conditions or technology changes." (Ken Schwaber, "Agile Project Management with Scrum", 2004)

"A list of all to-do items for an application used in Scrum, corresponding to the OpenUP/Basic concept of a work item list." (Bruce MacIsaac & Per Kroll, "Agility and Discipline Made Easy: Practices from OpenUP and RUP", 2006)

"In Scrum, the list of features not yet implemented by the application." (Rod Stephens, "Beginning Software Engineering", 2015)

"An ordered list of user-centric requirements that a team maintains for a product." (Project Management Institute, "Practice Standard for Scheduling" 3rd Ed., 2019)

"A listing of product requirements and deliverables to be completed, written as stories, and prioritized by the business to manage and organize the project’s work." (For Dummies, "PMP Certification All-in-One For Dummies" 2nd Ed., 2013)

"A set of software features awaiting development in a subsequent iteration." (Project Management Institute, "Software Extension to the PMBOK Guide" 5th Ed., 2013)

"The number of open or unsolved incidents. It is a running count of the difference between new tickets and tickets resolved." (Darril Gibson, "Effective Help Desk Specialist Skills", 2014)

"In an agile approach, the backlog is the set of requirements to be implemented in the project." (Cate McCoy & James L Haner, "CAPM Certified Associate in Project Management Practice Exams", 2018)

🚧Project Management: Scrum (Definitions)

"An agile method whose focus is on project management and requirements management. Scrum is often combined with XP." (Pramod J Sadalage & Scott W Ambler, "Refactoring Databases: Evolutionary Database Design", 2006)

"An agile software project management process introduced by Ken Schwaber and Jeff Sutherland. Scrum is known for self-organized teams, thirty-day iterations called Sprints, daily team meetings called Scrum, and a to-do list called Product Backlog." (Bruce MacIsaac & Per Kroll, "Agility and Discipline Made Easy: Practices from OpenUP and RUP", 2006)

"An agile process based on a football analogy, using small teams working in an intensive, independent manner." (Bruce P Douglass, "Real-Time Agility", 2009)

"An iterative incremental framework for managing projects commonly used with agile software development." (IQBBA, "Standard glossary of terms used in Software Engineering", 2011)

"An iterative, incremental methodology for project management often seen in agile software development, a type of software engineering." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A development methodology that uses frequent small increments to build an application iteratively and incrementally." (Rod Stephens, "Beginning Software Engineering", 2015)

"An iterative and incremental time-boxed method of developing software using small, self-directed teams. The goal of scrum is to flexibly develop what customers find valuable." (Pamela Schure & Brian Lawley, "Product Management For Dummies", 2017)

"An agile framework for developing and sustaining complex products with specific roles, events, and artifacts." (Project Management Institute, "Practice Standard for Scheduling" 3rd Ed., 2019)

"Iterative and incremental product development framework used in agile projects." (Jurgen Janssens, "Managing Customer Journeys in a Nimble Way for Industry 4.0", 2019)

"Scrum is a style of agile software development. It is built around the idea of iterative development and short daily meetings (called scrums) where progress or problems are shared." (Alex Thomas, "Natural Language Processing with Spark NLP", 2020)

"An agile process framework for managing knowledge work, with an emphasis on software development." (Kamalendu Pal & Bill Karakostas, "Software Testing Under Agile, Scrum, and DevOps", 2021)

"An iterative and incremental software development to handle drawbacks of traditional development methodologies. It produces many releases in short times based on customer requirements, time pressure, competition, product quality and available resources." (Fayez Salma & Jorge M Gómez, "Challenges and Trends of Agile", Balancing Agile and Disciplined Engineering and Management Approaches for IT Services and Software Products, 2021)

#️⃣Software Engineering: Programming (Part VI: What is Programming About?)

Software Engineering Series

According to Wikipedia, computer programming (shortly programming or coding) is “the process of designing, writing, testing, debugging, and maintaining the source code of computer programs”. That’s an extensive definition, because typically programming refers mainly to the writing of a set of instructions understandable by a computer or any other electronic device. At least that’s what programming was at its beginnings. 

With time, giving the increasing complexity of software, programming included also activities like gathering requirements, architecting, designing, testing, debugging and troubleshooting, refactoring, documenting, configuring, deploying, performing maintenance, etc. Each of these activities comes with their own set of methods, procedures, processes, models, methodologies, best/good practices, standards and tools. In addition, when we look at the architecture of an application, we can delimit several layers: server vs. client, front-end (user interface), business layer, backend (database), transport (network), communication or hardware – they coming with their own set of technologies and knowledge luggage, and requiring some specialization too.

However, making abstraction of all these, programming implies the (partial) knowledge of a programming language, an artificial language used to communicate with machines, in terms of language syntax, semantics and built-in libraries, and of a IDE (Integrated Development Environment), an application in which the code is written, compiled/interpreted and debugged. As programming can be often a redundant task, being necessary to solve the same kind of problems or to write the same kind of instructions, in addition to the various structures and techniques made available in order to minimize redundancy, a programmer can take advantage of a huge collection of algorithms, abstracted step-by-step instructions, and afferent technical literature. The deeper needs to go their understanding, the broader the set of knowledge to be acquired for it.

And even if we consider all above, that’s not enough because programming is used in order to model and solve business-specific problems. So is required some minimal knowledge of the respective business domains, and that’s quite a lot if we consider that each project may address one or more business domains. Talking about projects, as most of the programming is performed within projects, a programmer needs to have some knowledge of the procedures, methods and methodologies for project management and team management. That’s not programming anymore, but it’s part of the landscape and nowadays is kind of a must because programming is performed within projects and teams. This means also that a programmer needs to cover several important interpersonal skills, to which add up customer oriented, social and thinking skills. They are important because they impact directly or indirectly the act of programming, and many ignore this.

It’s important to stress that programming is not only the knowledge of languages, algorithms, tools, methods, models, practices, methodologies, standards, but also their adequate use in order to make most of the programming experience. Or as a long time ago retrieved quotes puts it: “programming is 10% science, 20% ingenuity, and 70% getting the ingenuity to work with the science” (anonymous). We all (or almost all) master our native language to the degree of writing sentences or communicating, though it takes skills to communicate effectively and efficiently, or of making from language a tool of expression through poetry or other forms o literature. Fantasizing a little, programming is like writing poetry, is one thing to write chunks of words, and another thing to write something meaningful. And programming is a lot about interpretation and representation of meaning in order to solve problems, is about understanding and breaking down complexity to a level that can be translated in meaning to machines. 

Programming is an art, to the same degree each endeavor can be transformed in art. It requires skills, knowledge, dedication, creativity, and most of all the pleasure of programming. Programming is a state of spirit, is a way or model of thinking, of seeing the whole world in computable terms.

Previous Post <<||>>  Next Post

🚧Project Management: Acceptance Criteria (Definition)

"The criteria that a product or product component must satisfy to be accepted by a user, customer, or other authorized entity." (Sandy Shrum et al, "CMMI®: Guidelines for Process Integration and Product Improvement", 2003)

"Those criteria, including performance requirements and essential conditions, which must be met before project deliverables are accepted. " (Cynthia Stackpole, "PMP® Certification All-in-One For Dummies®", 2011)

"A set of conditions that is required to be met before deliverables are accepted." (For Dummies, "PMP Certification All-in-One For Dummies" 2nd Ed., 2013)

"Those criteria, including performance requirements and essential conditions, which must be met before project deliverables are accepted." (Jeffrey K Pinto, "Project Management: Achieving Competitive Advantage" 5th Ed., 2018)

"Formal agreement that a service, process, plan or any other deliverable is complete, accurate, reliable and it meets its specifications" (ITIL)

"The exit criteria that a component or system must satisfy in order to be accepted by a user, customer, or other authorized entity." [After IEEE 610] (Software Quality Assurance)

🚧Project Management: Corrective Action (Definitions)

"Acts or deeds used to remedy a situation, remove an error, or adjust a condition." (Sandy Shrum et al, "CMMI®: Guidelines for Process Integration and Product Improvement", 2003)

"The process of returning some aspect of project performance to a more desired state." (Timothy J  Kloppenborg et al, "Project Leadership", 2003)

[Corrective feedback:] "Instructional responses to learner answers to a practice exercise that tell the learners whether they answered correctly or incorrectly. Contrast with explanatory feedback." ( Ruth C Clark, "Building Expertise: Cognitive Methods for Training and Performance Improvement", 2008)

"Documented direction for executing the project work to bring expected future performance of the project work in line with the project management plan." (Cynthia Stackpole, "PMP® Certification All-in-One For Dummies®", 2011)

[Corrective Feedback:] "Instructional responses to answers to a practice exercise that tells the learner whether they answered corrected or incorrectly. Contrast with Explanatory Feedback." (Ruth C Clark & Richard E Mayer, "e-Learning and the Science of Instruction", 2011)

"The response, such as defect repair or preventive action, to any shortcoming found in a quality audit." (Bonnie Biafore & Teresa Stover, "Your Project Management Coach: Best Practices for Managing Projects in the Real World", 2012)

"An intentional activity that realigns the performance of the project work with the project management plan."" (For Dummies, "PMP Certification All-in-One For Dummies" 2nd Ed., 2013)

[Corrective controls:] "Mechanisms that repair damage caused by an undesired action and limit further damage, such as the procedure to remove detected viruses or the use of a firewall to block an attacking system." (Weiss, "Auditing IT Infrastructures for Compliance" 2nd Ed., 2015)

🚧Project Management: Scope Creep (Definitions)

"Adding features and functionality (project scope) without addressing the effects on time, costs, and resources, or without customer approval." (Cynthia Stackpole, "PMP® Certification All-in-One For Dummies®", 2011)

"The tendency for people to sneak extra work and outputs into the project’s list of responsibilities. Can cause a project to fail under the burden of additional work without the corresponding resources." (Mike Clayton, "Brilliant Project Leader", 2012)

"The uncontrolled expansion to product or project scope without adjustments to time, cost, and resources." (For Dummies, "PMP Certification All-in-One For Dummies, 2nd Ed.", 2013)

"Additional activities beyond the defined or expected scope of a project. Scope creep often results in missed deadlines and increased costs." (Darril Gibson, "Effective Help Desk Specialist Skills", 2014)

"When the original plans or goals of a project expand. Common with projects, particularly poorly planned projects." (Weiss, "Auditing IT Infrastructures for Compliance, 2nd Ed", 2015)

"When features, functions, or attributes are added to a product during development that goes beyond the agreed-upon product requirements. When this condition occurs, the product is said to be experiencing scope creep. Scope creep is generally considered to be the number one cause of cost and schedule overruns in development projects. (Alternatively, this is sometimes called feature creep.)" (Steven Haines, "The Product Manager's Desk Reference", 2008)

"Adding features and functionality (project scope) without addressing the effects on time, costs, and resources, or without customer approval." (Jeffrey K Pinto, "Project Management: Achieving Competitive Advantage 5th Ed.", 2018)

"The insidious expansion of the product scope (i.e., expected functionality of the product, service, system, or result) that also expands or increases the project scope (i.e., the amount of work required) without a commensurate adjustment to or trade-off in the schedule, budget, resources, and/or quality, resulting in increased risk for the Performing Organization." (H James Harrington & William S Ruggles, "Project Management for Performance Improvement Teams", 2018)

"Also called requirement creep, this refers to uncontrolled changes in a project’s scope. Scope creep can occur when the scope of a project is not properly defined, documented and controlled. Typically, the scope increase consists of either new products or new features of already approved products. Hence, the project team drifts away from its original purpose. Because of one’s tendency to focus on only one dimension of a project, scope creep can also result in a project team overrunning its original budget and schedule. For example, scope creep can be a result of poor change control, lack of proper identification of what products and features are required to bring about the achievement of project objectives in the first place, or a weak project manager or executive sponsor." (ISTQB) 

🚧Project Management: Project Charter (Definitions)

"A document issued by senior management that formally authorizes the existence of a project. Provides the project manager with the authority to apply organizational resources to project activities." (Timothy J  Kloppenborg et al, "Project Leadership", 2003)

"A document issued by an executive, project sponsor, or customer, announcing a project and delegating authority to the project manager." (Bonnie Biafore, "Successful Project Management: Applying Best Practices and Real-World Techniques with Microsoft® Project", 2011)

"A document issued by the project initiator or sponsor that formally authorizes the existence of c a project, and provides the project manager with the authority to apply organizational resources to project activities." (Cynthia Stackpole, "PMP® Certification All-in-One For Dummies®", 2011)

"A statement of objectives, scope, and stakeholders or participants in a project or program." (DAMA International, "The DAMA Dictionary of Data Management", 2011)

"A document officially announcing an approved project. Distributed by the project sponsor, the charter identifies the project manager and the extent of the project manager's authority." (Bonnie Biafore & Teresa Stover, "Your Project Management Coach: Best Practices for Managing Projects in the Real World", 2012)

"a project management document that defines a project scope, objectives, benefits, assumptions, etc. May also identify team assignments, project sponsor, time and cost estimates and constraints, and areas that are out of scope." (Bill Holtsnider & Brian D Jaffe, "IT Manager's Handbook" 3rd Ed., 2012)

"A document that formally authorizes a project to move forward. Having such a document reduces project cancellation risk due to lack of support or perceived value to the company. A charter documents the project's overall objectives and helps manage expectations of those involved." (Robert F Smallwood, "Information Governance: Concepts, Strategies, and Best Practices", 2014)

"The project charter is the document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities. It documents the high-level information on the project and on the product, service, or result the project is intended to satisfy." (Cate McCoy & James L Haner, "CAPM Certified Associate in Project Management Practice Exams", 2018)