Wouldn’t it be great if we had this AI or the next big things!

Back in 1977 George Lucas and 20th Century Fox released one of the greatest movies that I have ever seen. To this date, Star Wars: A new hope has made more money for Fox studios than any other film of its time; kudos to you Mr. Lucas! This movie gave us a glimpse of what we might expect in the future and I loved it.

Now-a-day, we enjoy some of the devices as shown on Sci-Fi movies and shows such as mobile phones, self-driving cars, and personal computers; but I was hoping for much more.  For example, in the Star Wars movies, they had holographic communicators; by now we should at least have see through phones.

Holo-Comm See-thru phone
Why are manufactures having trouble building the products people want?

Working with Technology

8 easy things to remember…
I wrote this guide to provide business partners with thoughts on an easy and efficient way to engage their technology partners. 
It’s not always easy to embrace technology as it can be rather complex, my aim was to provide a simple guide to working with technology in order to drive project success.  Although the post is long, I’m hoping that you find it useful and will share it with others.


A blog for success by Richard Kottke
 Business to Technology Engagement History

Just as there are several ways to manage a project, there are many ways to engage in technical projects.

In the early to mid 20th century the modern computer was developed. This gave us the advantage of a computational machine that would complete business related tasks in a fraction of the time that it took a human resource to complete. At nearly the same time, computer science related project management became recognized as a discipline instead of the ad-hoc process of managing projects through a scheduled number of tasks.

Prior to this time, formal technology engagement was virtually non-existent. An assigned business lead would reach out directly to the technologist and provide them with spec’s on what was to be built. Most of the time the Research and Development group fulfilled the role of the technology group. There were no PC’s at that time and most main frame computers were leased from the major computer manufacturers or universities.

As the costs and size of computers came down, the need for project manager engagement with technology began to rise. Organizations discovered the numerous reporting capabilities of systems and requested technical projects from these systems. However, the engagement was undisciplined and unruly causing many delays and setbacks in project completion.

History of Advanced Computing Technology

Advanced Computing Technology – starts with the evolution of computing machines and software

Although there are several methodologies, programming languages, and hardware not included in the above timeline, the items listed have had a significant impact on today’s technological advances. With the innovation of the of the modern computer (CPU, memory, and peripherals), technology has moved forward in an unprecedented pace.
Technology has the ability to meet business needs at a much faster pace than it did in past. However, the ability to harness that power has been a challenge over the last 60+ years. Machines don’t speak a “human” language, nor do they comprehend human abstract thought. Thus, we rely on human technologists to explain/relay human thoughts to technology. The problem with that is we are all individuals and have unique ideas on how things should work. Applications developed through technology must be carefully planned in order to deliver expected results. Some of this is seen through the business use of methods that were developed specifically for building software applications, i.e. – Waterfall, Spiral, RAD, and Agile methods. Although these methods have their origins in software development, they have become ingrained in project management and are frequently discussed with business partners to ensure that the business receives expected product.


Through the 50’s to 70’s the need for a separate Technology team for the average to large company was rare. The equipment was expensive and the technologist were specialized and limited in ability. The existence of business administrative applications were also limited and those that did exist were mainly financial in nature. Because of these limitations, the technology teams that existed were managed and reported to the finance department.
The need for technical teams within an organization came about with the mass production of smaller hardware, faster software, the creation of online/mobile applications, and the ability of computers to perform complex tasks. With the rise of modern computing systems, leadership redefined their organizations similar to the image below. Several new departments were created to handle the technical needs.

In most current environments, these departments don’t report to business management. This would suggest that these resources are viewed as performing a separate function within the organization and thus work under a separate agenda. This may differ from the businesses itinerary.

Business, Technology, and Others…

Technology has a symbiotic relationship with other parts of an organization. It must work hand-in-hand with others to complete finished products.
  • Technology is responsible for producing products based on Business specifications.
  • The Business is responsible for creating products that meet the organization’s objectives.
  • Other parts of the organization are responsible for the guidelines and quality that are used to manage technology and confirm a quality product

Easy things to remember when working with Technology

The organizational funding process can be complex as it involves the entire organization. Since it is organization wide, the funding request from each group differs and may lead to disorder between the groups looking for funds. This misalignment usually causes a number of problems for both the business and technology groups, examples of these ‘direct impact’ issues are listed to the right.
Projects are expensive, not having startup funds to investigate, the time-frame, requirements, and resources to develop a new product can lead to problems. The business would like to create new products that not only meet customer needs, but follow the organizations direction and turn a profit for the organization. In order to realize the project’s cost benefit, there is a need for a high-level estimate of what the product will cost to build and get into production. There may be a thought that the tech partners will provide such a high-level estimate for free, that is not always the case.

Why, because in most cases technology is considered a profit center. This means that the business will need a cost center to bill tech project work, this includes providing high level estimates. If the project has a technical component, the business team will need to engage technology to get an initial project cost estimate.

The lack of required project approvals will slow down if not stop project work. Without these approvals, in most cases the project will be doomed for lack of support from stakeholders within the organization.


It is key to ensure that those stakeholders impacted by the project support the project. Stakeholders that have a perception the project will negatively impact their world must be notified of the project. They must have a good understanding of how the project will benefit them and the organization. Without stakeholder buy-in, the project is likely to fail. Getting approval up front will aid in project support, even from the nay-sayers.
The usual required  approvals:

  • Business case and benefits
  • Stakeholder approval
  • Funding
  • Risks, issues, and changes
  • Project Charter – PM authority to work on the project
  • Governance Document – project resources
  • Project Management Plan

In order to succeed, Technology must work with all parts of an organization. However, as part of that success it must not be tied directly to one specific part of the business. Technology must manage it’s own resources independently to be successful. It shouldn’t be aligned directly with others.
Technology uses a complex series of actions and steps to build product. This process has at least five phases and is used as the foundation to successfully meet customer’s requirements. The process includes steps for initiating, planning, designing, estimating, developing, managing, testing, and delivering the final expect product. The process is used to control project budget, risks, issues, resources, and communication.


Incorrectly engaging the technology group can lead to many problems such as cost overruns, unidentified risks and issues, project delays, incorrect estimates and so on.
Engaging Technology too early can lead to scope creep, funding issues, time delay and additional project costs. You may encounter project bias, early project spend, unneeded resourcing, and unwanted features.
Business product managers spend a lot of time researching and developing the right product. The product analysis should be complete prior to engaging technology. Allowing technical influences at this time would cause a deviation from the planned product.

Direct impacts to the product/project would include:

  • Additional Time
  • Stagnate or additional resources
  • Monies spent on non-project work

If engaged too early in the process, Technology partners may want to impose their thoughts on the finished product. This is not within their realm and can lead to a product that is not usable in the market…

SDLC is a process for working through the development of a new product.

  • The process starts with an initiation phase to confirm requirements and to get ready for design
  • Once design is complete, development or the build phase begins
  • After development is confirmed to be complete the project moves to the testing
  • This is where the Business will do UAT testing and approve the project to move forward into production
  • The final piece is approval and acceptance of the completed product.
  • Once approved, the product moves to production and the team moves on to the next technical project

In past years, technology would perform testing. This included such groups that supported the testing effort. In modern times, testing is managed by test management. This team is responsible for testing the product to ensure the final product meets approved requirements.

Testing Management – the Technology PM works with the testing management team to assign a Test Manager. The Test Manager provides the Test Management Plan.

Test Managers – Test Managers create the test schedule, review the plan and schedule with the project team, and obtain test planning approvals. Once approved, the testing team will move on to building test cases that tie back to requirements.

Project Testing – Testing is usually broken down into testing types such as:

  • Unit Testing – Testing done during development
  • System Integration Testing – a testing process to test coexistence with other apps or systems
  • User Acceptance testing – UAT is the last performed testing prior to acceptance. The results are usually used to secure product acceptance and approval

Developing and implementing new products may have a direct impact on the current organization systems. Depending on the product, the impact can be so great as to impede existing organizational products in production and lead to higher than expected errors and defects. The Test Manager or Project team should have a plan to manage and control cross system project impacts, most larger organizations have a separate group that manages the cross-system impacts.

Business partners may be unaware of a department within the organization known as Release Management. Release Management is the team that identifies, manages, and controls project implementation as well as cross-system impacts. Without this type of management, a project may impact another organizational system in such a way as to cause it to fail. Obviously, this would have a negative impact to the organization and needs to be avoided.

The RMO:

  • Monitors and controls all implementation activities
  • Confirms System Cross Dependencies
  • Plans and Schedules release work on a yearly basis

The inability to hold your technology accountable for their work will cause project delivery issues.

Impacts include:

  • Missed deadlines
  • Delays
  • Rising costs
  • Unclear expectation
  • Additional risks
  • Unclear design
  • Not getting the product you want.

Keep in mind, your Technology Partners are there to help you.


If you have any questions, need clarification, or want to learn more…

Contact your IT Director or Program Manager if you have any questions about working with Technology. These resources can aid in pulling in other technological groups (the PMO, Technology, Leadership) as required.

A PM’s guide to adding ‘Change’ to your projects


Change can be a frightening word to most people, especially when it is used in the context of a corporation. However, we encounter change on a daily basis and we may not even notice it. Change is a part of life and thus it is part of all projects. Projects themselves cause change and because of this change there will be resources that will fear and resist the project. How do you as a good project manager manage to that change? Easy, you engage a change manager. Oh, you don’t have a change manager, well that makes it a little more difficult but not impossible.

Managing change in a project can be easy if you add change to your project. What do I mean by that, start with your project charter as it will give clues as to how the project will impact employees and customers alike. I’m going to outline thoughts on determining high level needs and tasks to add to your project plan that address change. This is meant to provide a basic overview of what change management to expect as you plan your project.

For clarity sake I’m going to break this down into two separate pieces, the first will talk about determining change. The second will discuss adding possible change tasks to your plan.

Determining project change needs

Setting some ground rules as it’s always easier to work from a foundation. I’ll use a scenario that an organization has standard project classifications, for this discussion the project standards will be broken down into four classifications based on risk and project cost. Please keep in mind, your organization will most likely use different project classification standards. The following figure outlines the classifications used in this article; Class A represents the highest risk and cost classification and on the opposite end, the N/A class is the lowest risk and cost.

The reason for classifying projects into these groups is to outline that projects themselves can be classified much like object oriented classes, i.e. they have attributes, they contain functions, they can be governed by other projects or groups, and once instantiated they represent an implemented finished product. See the figure below for a breakdown of a project class. More on this at a later date as the focus of this article is to discuss adding change tasks to projects.

A project is and contains:

Attributes Functions Definition Examples
  • Non-routine
  • Start & end
  • Cost/budget
  • Scope
  • Well defined
  • Provide Change
  • Developmental
  • Transformational
  • Scope
  • Project Plan
  • Resource Plan
  • Schedule
  • Implementation Time
  • Implementation Cost
  • Budget
  • Risk
  • Budget
  • Progress
  • Issues
  • Benefits
  • Performance Metrics
  • Projects are individual or collaborative endeavors that are carefully planned and designed to achieve a particular aim.
  • Projects contain a defined scope, cost, and timeframe
  • Projects introduce change to the organization
  • They are not part of Business as Usual Operations.
  • Launching a new product or service
  • Upgrades to systems and installation of new equipment
  • A change in the current process or system

Project change requirements/expectations

Now that project classifications have been outlined, the expectation of change in each classification can be discussed. The picture below outlines the amount of expected change per classification.

As the project grows in complexity, cost, length, size and risk the requirements to plan for change grow. Thus, the larger need for a change management team and additional planning must be added to your project to combat the change impact that will happen in your project. For those interested in what to expect as ‘Change’ tasks in your project, please read on.

Plan for Change in your project – adding tasks to your project

So you’re interested in what to add to your project at a high level, in order to address change. To discuss change tasks there is a need to look at how change tools as Change tools aid in understanding how change impacts projects. The project life cycle outlines the phases that we go through to implement a project, the six items listed explain some of the tools that are used to identify change in your projects. Using the outlined tools will aid in determining the amount of change, change level, and when to expect the change in each project.

Working through a project change assessment is a first step to understanding the scope and complexity of the change within the project. This type of an evaluation gives the Project Manager a sense of the risk level and amount of change that is expected in the project. High risk levels or large process changes would indicate a larger number of change tasks are needed to complete the project. Also, a Change Manager should be engaged to aid in project development and implementation as indicated.

Possible High-level Tasks to add to your plan around Change Assessment

Change Assessment
Complete a project change assessment
Pre-assess project for Change impact
Meet with a Change manager to assess project
Identify Change complexity
Discuss assessment with LOB
Project Change reassessment #1 – Post planning
Project Change reassessment #2 – Post design

A change story will aid in identifying the change in your projects. Working through the Change Story, the team will uncover issues and risks, create a project story, and describe the What, Why, When, and How that are used to complete the project. The Change Story will be a driver into many of the other documents in the project.

Possible High-level Change Story Tasks to add to your plan

Conduct and Approve Change Story
Meet with Change team to discuss Change Story
Conduct Change Story Session
Complete Change Story template
Vet Change Story with Subject Matter Experts
Share Change Story
Meet with Sponsor to discuss Change Story
Obtain approval of the Change Story
Complete the Change Story
Confirm Business Scope and Benefits
Meet with LOB to complete/receive Business Case
Draft Project Charter
Confirm project benefits

The stakeholder assessment will aid in understanding the need for resources, confirm that you have engaged the correct resources, and aid in determining stakeholder influence.

Assess Stakeholder Groups
Meet with Sponsor
Identify Business Resources
Confirm Business Resource effort commitment
Identify Tech, Marketing, Process, Customer Experience, and Sales Effectiveness resources
Identify critical vs non-critical resources
Identify Change management needs
Assess resource influence
Assess Stakeholder Needs
Confirm Stakeholder Groups
Review SMEs for compliance/risk/legal
Meet with Subject Matter Expert project manager
Draft Subject Matter Expert list
Create draft Governance Document
Identify Marketing, Procedural, Customer Experience, and Sales Effectiveness resources
Setup Core project group meetings

Change Management Strategies determines how and when you will work with employees and customers






Leadership Engagement
Identify leaders’ thoughts on participation
Create an engagement strategy
Identify knowledgeable resources
Discuss various engagement vehicles
Determine best engagement vehicle
Confirm communication vehicle
Confirm leaders wants and needs
Confirm success factors
Outline each want and need
Identify engagement risk and socialize
Customer Communications Strategy
Identify project impact to employees and customers
Determine Marketing Communication Strategy
Meet with subject matter expert project manager
Draft subject matter expert list
Create draft Governance document
Identify Marketing, Procedural, Customer Experience, and Sales Effectiveness resources
Setup Core project group meetings









Employee Training Strategy
Identify project impact to employees and customers
Meet with training coordinator
Identify training resource (the trainer)
Identify employee training needs
Confirm training budget
Create a training plan
Get sponsor approval on training plan and budget
Create or update training material
Setup Core project group meetings
Other Strategy Tasks
Review and confirm project resources and governance
Remove old and add new resources to the project
Conduct follow-up meetings with communication groups
Meet with Change team to confirm change resistance plan
Consider and discuss project Pilot with Sponsor
Discuss and confirm success factors and indicators with Sponsor

The detailed change management schedule contains the tasks that aid you in managing project change

Detailed Change Planning
Meet with organizations customer and employee advocate stakeholders
Identify change impacts
Outline items that will change
Draft changes
Meet with other stakeholders to discuss change items
Finalize Change Items
Obtain changed items approval (Leadership/Legal/Compliance/Risk)
Plan change implementation
Revisit and walkthrough Change Plan
Announce Change
Conduct a Dry Run implementation
Review dry run results and change the plan accordingly
Plan for communication
Identify communication needs
Obtain final communications approval
Communicate Change
Confirm message received and understood

Once the project is implemented – the sponsor and business will need to take-over/own the product

Project Exit Tasks
Meet with organizations customer and employee advocate stakeholders
Confirm project delivery date
Review milestones for completion
Deliver metrics

Hopefully, this gives a good understanding when and what ,at a high-level, to add to a project plan to account for change.