• 

Step Three

Set project expectations with reasonable deliverables, timelines, and milestones

Project Definitions

Software projects may be commonly categorized as technical, functional, or transformational. Additionally, a project’s complexity may be characterized as being low, medium, or high. How one establishes and sets project expectations may be methodically similar for each; but, every project will have its own unique nuances and strategy.

• Technical – Characteristics: Mostly there are retained business processes; but, there is a change to the technical environment. Moving from an on premise IT data center to a hosted Cloud environment could be an example of a technical project.
• Functional – Characteristics: Mostly there is a retained technical environment; but, there are new or updated business functions to address changing business needs. Installing a CRM program to track customer information is an example of a functional project.
• Transformational – Characteristics: There are significant changes to business functionality because of changing or evolving business needs; and, there may also be accompanying modifications to the technical environment, usually to address new business issues. For example, mergers and acquisitions often require transformational software projects to blend new companies together, especially if both have different ERP systems involved.

 

• Low Complexity – Characteristics: There is a limited customization effort, if any; a low number of modules are involved; impact to business process/changes are limited; low staffing resources are required; duration is less than a few months; it is a low risk project; and, an ROI is projected to be less than 1 year. Installing an ERP technical tools upgrade, or installing a new report writing program are examples of a low complexity project.
• Medium Complexity – Characteristics: Some customization or personalization effort may be required; an increased number of modules are involved; more business process/changes are impacted; increased resources are required; duration may be six to twelve months; it is a medium risk project; and, an ROI may be projected between 1-2 years. Installing a new human capital management (HCM) program would be an example of a medium complexity project that can touch multiple programs within a company’s ERP environment.
• High Complexity – Characteristics: There is significant customization or personalization effort required; a large number of modules are involved; significant business process/changes are impacted; many resources are required; duration may be twelve months or much longer; it is a higher risk project; and, an ROI may be projected between 2-5 years. Implementing an advanced warehouse and logistics tracking program to augment an existing distribution software environment, or implementing a new brand new ERP program with many edge program applications would be examples of a high complexity project.

 

Setting Expectations with Well-Defined and Reasonable Deliverables in Mind

Never bite off more than one can chew, goes the old adage. Software projects should follow suit by setting expectations outlined by easy-to-understand parameters, well-defined tasks, and measurable project deliverables. For all software projects, tasks need to be prioritized, staffed appropriately, sequenced properly, and thought-out in advance to make the best use of resources, time, and budget.

To illustrate, in a construction project, a concrete foundation is an essential first step before starting the building’s framework. But, before the concrete is poured, site surveys must be conducted, boundaries must be fixed, wooden or metal forms must be erected, and the site must be physically prepared before starting the concrete work. Similarly, for software projects, before any software can be configured, tested, and verified, a site survey and discovery to understand one’s core business processes, and any impacted business procedures, is an essential first step in the process to define, design, and plan a software project. And, if there is any integration required with other programs, this integration effort must be detailed and planned in advance, too.

Timelines

Timelines can be difficult to estimate and plan for three reasons. (1) As much as one may try, some things can influence projects that are totally out of one’s control. Business priorities can change; economic conditions can change; and, operational circumstances can change. (2) For complex projects in some organizations, one may end up sharing staffing resources with other prioritized projects, which can cause delays. And, (3) project constraints can be negatively impacted by the following: a project’s length of duration; any shift in budget finances; and, and unforeseen demands on team members. Projects may need to factor in adequate time for holidays, vacations, and normal business activities; as well as, a team member’s regular job role and responsibilities.

A project’s complexity always impacts a project’s duration. Generally speaking, the larger the scope of a project, the longer it will take to be completed. I am often asked if there is a way to compress the amount of time required. The answer is a highly qualified maybe.

By increasing the size of the team, one may be able to shorten some aspects of a project. And, by lessening a team member’s regular job responsibilities, one may free up more time that can be spent on project tasks. But, there are usually points of diminishing return that one can reasonably control. Increased resources, and focused time, may only improve certain parallel project processes. Sequential processes may need to be closely monitored.

Milestones

Milestones chart the progress of a project’s work effort along a planned course of action. One must be mindful of common project constraints, which are identified as (1) staffing availability (people), (2) resource availability (materials, facility access, technical, mechanical), (3) time mandates (to meet a specific date, to comply with a business requirement, or to meet a legal compliance target), and (4) budgetary (which is frequently re-evaluated quarterly to review and align with revenue attainment). Changes to any one of these four constraints can both negatively and positively influence the others. Increasing staffing might reduce the time required to complete a step; but, it may also negatively impact a staffing budget goal. Conversely, reducing staffing may positively impact a staff budget goal; but, it may negatively stretch out a timeline causing a missed milestone date.

For complex projects, there may be advantages to using smaller, more manageable milestone steps, with each smaller step having its own unique milestones goals.

Step Two

Formulate a detailed blueprint for your team

Blueprints

Every project needs a detailed blueprint. Whether one is a construction project manager, or one is a software project manager, both jobs require clear, concise, and detailed instructions to insure a successful outcome. And, for every project, one must have well-defined, achievable, and measurable goals to gauge the final outcome of the project.

The more detail that can be captured upfront will lessen the chance of project creep, and budget over runs; plus, the proficiency of a team’s upfront work effort can maximize a projects’ outcome and its potential ROI results.

Often project stakeholders – executives and/or power users – have unique goals that are specific to their position, their department, or for their area of responsibility. All collective goals should be documented within the project plan, prioritized, and agreed upon by the team prior to the project starting.

Project Reasons and Characteristics

The need or reason for a project may be the result of valid internal requirements (specific business needs), or external requirements (specific legal reasons or cost-of-doing business). Whatever the reason, there should be ample supporting details in the planning documents.

Aside from goals, projects may be influenced in some form by budgets, resources, events, activities, and time. Each of these should be clearly detailed in the project’s blueprint.

One universal goal for all team members and stakeholders should be to have no surprises, hidden costs, or unexpected results at the end of the project.

PREFACE:

When asked for guidance by busy executives, often with limited experiences in software project preparation and development, on how best to plan for a software implementation, migration, or upgrade project, I am happy to provide practicable and sound advice based upon my twenty-five plus years of cumulative software experiences.

While every project may have its unique needs and requirements, I have found that when these six commonly shared steps are properly addressed, software projects tend to travel a smoother path. Plus, projects seem to have a quicker ROI, and a better chance of being successful, if the suggested attention-to-detail can be achieved at each step.

• Step One – Build a project team to match project needs
• Step Two – Formulate a detailed blueprint for your team
• Step Three – Set reasonable deliverables, timelines, and milestones
• Step Four – Create a budget and set an ROI target goal
• Step Five – Establish reporting guidelines and change processes
• Step Six – Assess risks if project goals and deadlines are missed

My recommended project approach is one of applying best case traits and proven methodologies, which can be emulated every time to create repeatable and predictable project results.

Successful software projects are never open ended; and, they are always framed by engagement delivery tasks that are due within a specified amount of time, and within a specified budget. Please note that these six steps are not all inclusive for every project; and, because projects may vary in goals, scope, and complexity, additional steps may be necessary or required.

Step One

Build a project team to match project needs

Building a Team

Software project teams vary in membership size and skill sets, all built around the complexity, scope, and timing of a project. Core ERP project teams typically start with 5 to 10 members. However, for many projects, it may be common for teams to dynamically expand and contract as functional and technical phases may be addressed and completed.

Team member roles, and their skill sets, are often designated as being either functional or technical. Functional roles are associated with specific business processes or activities; whereas, technical roles may be associated with general IT programming and/or technology processes or activities. In some cases, technical knowledge can also apply to knowledge of technical manufacturing processes for specialized packaging systems, including aspects of mechanical engineering, product conveyance, industrial plant process controls, and the like.

Regardless of a project’s scope, there are two required roles that every project team needs:

1. An executive sponsor, who champions the project, guides it through a budget approval process; and, often has the most to gain with its successful conclusion.
2. A project manager, who manages the team’s day-to-day work effort, coordinates resources, provides periodic project updates to the executive staff; and, has decision making authority to keep the project on track.

Depending upon time constraints of the project team, other project demands and commitments, or the availability of internal resources, outside consulting teams, are often utilized as partners to provide supplemental or complemental functional or technical expertise that augments or supports the needs of a core project team.