CIOs Practices for Dealing with Economic Uncertainty

 According to an article on CIO.com, economic uncertainty is one of the main concerns that keep a CIO (Chief Information Officer) up at night. Below I share some ways CIOs can mitigate the impact of changes to the economy.

Cost Optimization: CIOs should closely analyze their IT budgets and identify areas where costs can be optimized without compromising critical operations. They can explore options such as cloud migration, outsourcing non-essential tasks, renegotiating vendor contracts, or consolidating systems to reduce expenses.

Risk Assessment: Conduct a thorough risk assessment of the organization's IT infrastructure and operations. Identify potential vulnerabilities and develop contingency plans to mitigate risks. This may involve enhancing cybersecurity measures, implementing data backup and recovery solutions, and ensuring business continuity plans are in place.

Agile IT Operations: Implement agile methodologies within the IT department to improve responsiveness and flexibility. Agile practices enable faster decision-making, rapid adjustments to changing circumstances, and efficient resource allocation. This approach allows organizations to adapt quickly to economic fluctuations.

Strategic Technology Investments: Evaluate technology investments carefully, ensuring they align with the organization's long-term strategic goals. CIOs should prioritize initiatives that drive efficiency, innovation, and competitive advantage. They should also consider emerging technologies that can enable cost savings and improve productivity, such as automation, artificial intelligence, and data analytics.

Collaboration and Communication: Foster collaboration and open communication channels with other executives and departments within the organization. Engage in regular discussions to understand business priorities, challenges, and opportunities. This collaborative approach helps align IT initiatives with the overall business strategy, ensuring technology investments are focused on areas that deliver the most value during uncertain times.

Scenario Planning: Develop various scenarios based on different economic outlooks and assess the potential impact on IT operations and projects. By having contingency plans for different scenarios, CIOs can be better prepared to respond quickly and effectively to changing economic conditions.

Continuous Monitoring and Analysis: Establish mechanisms for continuous monitoring of economic indicators and trends. Stay informed about market conditions, industry developments, and regulatory changes that may impact the organization. This ongoing analysis allows CIOs to make informed decisions and adjust strategies accordingly.

Talent Management: Focus on talent retention and development within the IT department. Invest in upskilling and reskilling programs to ensure that the IT team possesses the skills needed to adapt to changing business needs. Retaining key IT personnel during uncertain times is crucial to maintaining stability and continuity.

Vendor Management: Strengthen relationships with key technology vendors and partners. Collaborate closely with them to negotiate favorable terms, explore cost-saving opportunities, and leverage their expertise in navigating economic uncertainty. Effective vendor management can help optimize IT investments and minimize disruptions.

Transparent Reporting: Establish clear reporting mechanisms to provide regular updates to stakeholders on IT initiatives, progress, and the value delivered. Transparent reporting builds trust and confidence among leadership, employees, and external stakeholders, especially during times of economic uncertainty.

By implementing these strategies, CIOs can proactively address economic uncertainty and help their organizations navigate through challenging times while maintaining operational efficiency and supporting business objectives.

Simply Ask "Why"

 It's more common than we think. Lack of end user perspective will ruin a product.

Yes these images are real. Check out this old post from 2009 https://sys-eng.blogspot.com/2009/04/one-way-to-ruin-great-product-idea-when.html

Looking at these three images at three different projects, its clear that even if on paper the design seemed feasible, the implementation team must have noticed the a little more than average steep driveway, or a little too high ATM, they even went out of their way to accommodate an opening 😱 for the lamp post in the balcony's floor.

👀 Did the implementation teams just throw a blind eye to the issue?

🙊 Maybe they assumed it would go away?

🏋🏼 Thought it was an undiscovered innovation?

These are just examples of everyday business issues that happen all the time. Sometimes minor like losing a customer, in others pretty devastating like losing an entire product line.

Allowing teams to speak freely their minds, and giving team members the authority to question decisions, and promoting respect and accountability are a few ways to mitigate errors in organizations.

The need becomes increasingly important with large portfolios, digital transformation initiatives and situations where projects are too fast or too slow.

Just go back to the simple question, WHY?

Agree?

The Impact of Multi-Factor Authentication

 

According to Google, using Multi-factor Authentication can block up to 100% of automated bots, 99% of bulk phishing attacks, and 66% of targeted attacks that occurred during its investigation, as reported earlier this year in a BusinessWire release which estimates the MFA market to reach $28 billion by 2026.

One of the most important factors in the success of an MFA deployment is user adoption. My experiences deploying MFA for thousands of end users is to engage early with the end users. Engagement typically follows a multi-stage process:

1. Leadership Education

It is important for the technology team to reach out to the leadership team on the business and end user side, to explain the benefit, impact to business risk reduction and improved data integrity. Discussions should also include a very high level of the technology and how it works (the concept of Who You Are, and What You Own).

2. Managers Engagement

Managers will be crucial when time comes for go-live to ensure all users have followed the instructions to activate MFA on their accounts. Managers will also provide lists of the users in their departments and their email addresses for the IT team to enable the feature on their accounts, which will allow end users to activate.

• Background on Cyber Security threats and risks
• What is MFA?
• Value Proposition and Benefits
• End User Impact
• Deployment Schedule
• User Guide
• Technical Support
• Learn More

3. End Users

End users will benefit the most from easy to follow user guides that include screenshots, clear step by step process to follow and information to provide the assurance they are moving in the right direction. A short 2-minute video will come in handy, as well as instructions on how to contact technical support should there be access issues. A table of contents of a good user guide is shown below:

• What is MFA
• Why MFA?
• When Will the Change Take Place?
• What Will the Change Look Like?
• Where Can I Find Information on Activating My Account?
• What to Do if I Have Questions?

Building a Business Intelligence Shop

Not sure where to start in building your business intelligence capability. Check these four major steps.

A. Strategic Planning

• Aligning capabilities to needs
• Cross-functional approaches and prioritization
• Understanding demands, dependencies, trends
• Digital transformation
• Define KPIs

B. Build the organization

• Build data-driven culture
• Build transparency and accountability
• Define data governance and data model
• Data architecture, modeling, design, storage and access, security, integration, interoperability, documents, content, master data, reference, data warehousing, metadata, data quality
• Leadership support
• Decision-making process
• Agility and funnel approach, change management and enablement

C. Managing the Work

• Portfolio management, demand management and alignment
• ROI and value management

D. Service Marketing

• Portals
• Dashboards
• Websites
• Reports
• Communications
• Customer Network and social interactions
• Marketing to persuade change and efficiencies, cross collaboration
• Monetization of data through updated strategic planning and capability building.

Business Intelligence

 Some key components for Business Intelligence are:

• Context
• Visual representation
• Forecasting approaches
• Machine learning
• Storytelling
• Analysis and meaning
• Action items

Telehealth Promises Higher Quality of Life for Rural America

It is not uncommon to find lesser access to healthcare capabilities in rural pockets of the world, and this holds true in the United States as well. A 2017 CDC report showed that death rates in rural America due to cancer are higher than urban communities. With recent changes to telehealth revenue models, and relaxed federal regulation, telehealth capabilities bring promise to areas that are hard to access service, as providers can extend their services into rural areas of states in which they are credentialed.

In June, the Federal Communications Commission (FCC) announced that it would be opening opportunities for healthcare providers to receive funding for infrastructure build-outs and improved access for patients. Funding can be used to provide clinical monitoring devices for patients's use at home, or telehealth software and hardware by providers.

Solo and small provider groups, along with large medical systems can extend their reach beyond their local zip codes. The playing field is not totally equal to all clinicians, but a specialist in Baltimore can certainly start providing telehealth services to residents in Western Maryland through the click of a mouse. The smaller practice can up with innovative billing models which still hold effective to the patient maybe even without using insurance, as they leverage lower overheads and direct personalized care. The larger provider groups benefit from the marketing economies of scale, more aggressive advertising, but are constrained by less flexible revenue models, large overhead, and the less than optimum agility to adopt solutions.

Many successful implementations have shown promise such as in the case of an oncology program in California which helped bring patients closer to caregivers especially during the brutal months of winter. The program reached accreditation by the commission on Cancer and has seen a growth of 8X over two years from 60 patients to 500 patients back in 2008.

The vendor and solution provider landscape is offering more innovation than a few years ago, and opportunities for easier access, higher value proposition and more personalized care with smarter revenue models cutting out the middle insurance broker are becoming more of a reality, especially in preventative and monitoring care. Generally speaking, patients adherence to long term is not strong, with closer engagement with their care providers the likelihood of adhering to guidelines and recommendations is much higher, leading to improved health outcomes.

Examples of telehealth solutions that are creating personalized experiences for patients through access to a stronger medical ecosystem are Siemens Healthineers, and Vianova. Standards groups such as Institute of Electrical and Electronics Engineers (IEEE) are actively working on interoperability standards for devices and data across solution providers. The IEEE P2933 work group focuses developing a framework for the clinical IoT data and device Interoperability with TIPPSS (Trust, Identity, Privacy, Protection, Safety, Security) principles. This includes wearable and other clinical IoT enabled devices and their interoperability with healthcare systems including Electronic Health Records (EHR), other clinical IoT devices, hospital devices, and future devices and connected healthcare systems.

#telehealth #patientmonitoring #P2933 #healthcare

Ayman Nassar is an industry expert in project and portfolio management with over 25 years experience in architecting business solutions through optimum alignment of technology and business to achieve meaningful results. He is also a member of IEEE P2933 helping bringing patients closer to improved quality of life through robust and seamless telehealth solutions. He can be reached at anassar@anassar.net or https://www.linkedin.com/in/aymannassar/

What is Your Telehealth Roadmap Strategy?

There is no doubt that COVID-19 has been a major catalyst in accelerating telehealth solutions. Many medical care institutions have had some flavor of telehealth prior to COVID-19. For some organizations the telehealth capability took the form of provider to provider consults. In other cases it could have been a simple portal where patients login and provide some basic information about their vitals and how they are feeling. COVID-19 however pushed the boundaries on every provider to find out ways to provide virtual encounters via video and audio remotely as both providers and patients have been quarantined and stay-home orders were in effect.

As healthcare organizations scrambled to deploy quick solutions which in some cases were not HIPAA compliant, and were far from fool-proof, leaders have to the realization of the need to operationalize the capability, as well as develop a vision for what it would look like over the short term, next 12-24 months. This need becomes of a higher need as regulations undergo some changes, compensation models innovation are occurring, and patients expect the service, not to mention potential subsequent COVID-19 waves as witnessed this morning in California as it re-enters into a State of Emergency.

So what are some considerations for a sound telehealth roadmap?

I like to break down the strategy into two distinct areas; the first is what I call the foundational phase, the second is the deployment and roll-out phase. Telehealth capabilities are more than technology. The successful realization of telehealth capabilities requires addressing culture, business rules, workflows, technology security, data analytics and operational key performance indicators (KPIs) in the clinical, revenue cycle and supporting operations areas.

Setting the foundation is the main focus of the initial component of the roadmap, and involves these activities:

1. Establishing a well-oiled enterprise portfolio management office. A group that can facilitate C-Suite discussions to define key business KPIs, and define approaches to track them on a daily basis, and view projects as investments translating delivered work into measurable value that can be translated into financial and operational metrics that the CFO and COO can appreciate and utilize. To maintain autonomy the group should have the empowerment to coach chiefs on thinking outside of their areas and think strategically. In some models the group would report to the CEO, or to all chiefs, but have autonomy to make decisions based on sound approaches and documented rules. Another common model is to have the group report to the CIO, as almost all solutions today are data-driven and technology enabled. Today's successful CIO's are those who speak in the language of the business and are empathetic with the needs of clinicians and their patients.
2. Fostering and nurturing an organizational culture of accountability, patient value proposition and organizational mission. Unfortunately, not too uncommon is many organizations in the industry suffering inefficiencies. Examples of these inefficiencies are clinician controlled organizations which tend to prioritize physician convenience over patient care reflected in scheduling rules, availability, triaging rules, decision making, patient volume accountability and documentation maintenance. Another common inefficiency is tactical leadership in the C-Suite that fails to think strategically across the organization, unable to define heat maps, or poorly identifying existing and needed business capabilities and lack of prioritization of initiatives, losing track of meaningful KPIs and creating silos. Focus should be on business rule simplification, process streamlining, capability and asset inventory, architecture documentation, and change management and enablement processes.
3. Investing in a strong supporting infrastructure represented in IT security, network and server technical capability, enterprise architecture, project management office, talent development, compliance and a legal support team. Unfortunately many healthcare organizations view their IT departments, legal team and HR recruiters as cost centers, rather than value development centers. Together these supporting teams can strategically build and support a strong value stream by weaving a strong strategy map in conjunction with the operational leaders of the organization, mainly in the clinical and revenue cycle sides. The formation of these guiding teams and the chiefs engagement directly with these teams is a key requirement for success. Chiefs shouldn't be immersed in fighting daily fires, leaving strategic growth initiatives to become second priority.

Next comes the deployment and roll-out phase which focuses on two main components

1. Problem Definition and needs analysis coupled with a visioning exercise checking its alignment to the organization's mission has proven very powerful to validate the scope of the telehealth roadmap and it's capabilities.
2. Solutioning and a strong market research of offerings, comparing off-the-shelf products and their fit to the healthcare organization's environment and configuration at a feature and use case level is the next value-add activity. This can be achieved through vendor presentations, RFPs, in person demos of well-defined use cases reflective of the organization's workflows. This piece of work should include integration concerns across vendors, and how the integration will address the organization's specific business rules and the level of adaptation of the technology to the changes in business and clinical operations.
3. Building a strong partnership model internally and externally with key stakeholders and vendors to implement the solution and telehealth capabilities under the oversight of the guiding team, utilizing the enterprise portfolio team and project management office as the internal auditors of the roll-out, providing continuous feedback and opportunities for process improvement.
4. Once these high level stages can be put into place, the problem of defining which telehealth model to deploy (virtual health, peer to peer consultations, third-party contracted services) becomes a simple task, followed by a more detailed definition of telehealth capabilities and types of clinical encounters and a roll-out plan across the various specialties or a big-bang approach.

In summary, before worrying about COTS vs inhouse implementation, or Electronic Health Record (EHR) and Practice Management (PM) embedded vs integrated solutions, or the features a doctor can perform, the organization needs to think strategically at a macro-level to build a solid foundation in an agile manner to ensure a valid business and revenue model. This will ensure a scalable roadmap that can be incrementally implemented providing value realization to both the organization and the patient, focusing on what matters and what makes the organization unique and well-positioned for longer term growth.

For more information on telehealth advisory services visit carefinitive at https://www.linkedin.com/company/68234600/admin/. Ayman Nassar is an industry expert in project and portfolio management with over 25 years experience in architecting business solutions through optimum alignment of technology and business to achieve meaningful results. He can be reached at anassar@anassar.net or https://www.linkedin.com/in/aymannassar/

Speak Up

Ever been in a meeting when someone is presenting a topic, or making a statement and then the discussion goes on, towards the end the facilitator asks if there are any questions or comments, and its all silence. Ten minutes after the meeting is over the complaints starting roaming around on emails and phone calls. People whining and complaining about that idea that was thrown out there, or that comment that was made in the meeting. Sounds familiar? So how does a project manger handle office rumors, perceptions, she said, he dictated. It's simpler than it seems, just speak up.

Speak up on calls, that is why we have them. to share your points and opinions and be heard. Otherwise keep your peace forever and do not complain off-line.

A Framework for Enterprise Portfolio Management

It's all about chosen the right set of initiatives and project to deliver the needed value at the right time and with the right investment. In Systems Architecture lingo its the optimum validated design, in stock manager lingo it a balanced nest. In the early 2000s I wrote extensively on value proposition and value management, the diagram below illustrate the position of value management across the grand scheme of things. Enjoy

ETL Move to Production Considerations

Extract, Transport and Load (ETL) work is a common method to connect systems using manual or scheduled batch jobs. Blow are common items worth considering when building an ETL and turning it over to your operations team. We holding knowledge transfer meetings the items below are usually of most importance.

 

Functional description

Batch / Automated Job Names

Frequency / Timings of Batch Jobs

Potential Errors

Error Handling

Exception Handling

Escalation Path

Diagrams

Interface Names

Server / System Names

ETL Tool Version / Vendor Support

Security Parameters

Project Governance Transitioning

Ocassionally project managers transition out from a project due to relocation to another business area, termination or incompatiable skill set. So what are some of the items that the new project manager needs to check and receive from the departing project manager? The list below is what I have found the most important artifacts to enable a smooth transition.

• Project charter
• Latest status report
• Open items punch list / issue list
• Progress Map (where does the project fit on the lifecycle of a typical project)
• Team / Stakeholder roster
• Approvals Matrix (list of approvers and evidence of approvals

 

Both departing and onboarding project managers should schedule a meeting to review these pieces of information, and then a followup meeting with the stakeholder to ensure all expectations are clear.

Software Transition Plan

Building a system is one thing and turning it over to production for the end users to reap it's utility is a totally different beast. Transitioning products to production involves training, documentation, support knowledge transfer, operational procedures, production readiness and end of life disposal. It is a complex process and requires good governance and leadership. A well known systems hueristic emphasizes that systems are least stable when transitioning from one governance mode to another.


Each of the areas above could require a detailed plan or set of checklists to ensure all needed actions have been considered. In this post we will focus on software products, and list below key items that should be included in a transition plan.


Training should cover all required functions by the end user, and should include special cases. emphasis should be on how to process business rules, verify transactions, run reports and review output. common artifacts used are handouts, videos, training web pages, online webinars, in person train the trainer sessions.


Documentation includes defect logs, knowledge base tip sheets, escalation procedures, notification requirements, schedules for batch jobs, lists of interfaces, details of interfaces, expected outcomes, lists of vendors, data sheets, user guides, admin guides, support levels and contacts. Requirements documents and functional specifications should also be shared with the operatonal support team for reference, manitenance and operational support puproses.


Support knowledge transfer usually takes place in progrsssive iterations in the form of meetings between the project development team and the operational transition team, it is a series of engagements of experts to transfer knowledge, review details of the software and identify all the transition requirements including the development of a transition plan and its execution.


Operational procedures are covered in the documentation above and also include run books, special processes for data archiving, licenses renewals, IT business functions and upport such as security audits, threat analysis and similar processes.


Production readiness covers the setup and installation of the software, user configuration, secuity profiles, smoke testing, functional spot checking, final hardware configuration and monirtoring systems (reportsing / dashboards) setup.


Finally end of life support should be considered at time of transition to ensure the user population understands how to dispose of the software at end of life, how to extract data and migrate into industry standard formats as needed.


The links below provide some more details and templates


https://www.projectmanagement.com/content/processes/10352.cfm


https://www.projectmanagement.com/content/processes/10350.cfm 

Performance Challenges on the Cloud

 

 

A typical cloud implementation could have hundreds of CPUs running in parallel. Some cloud solutions could be like an S-class Mercedes, however to leverage its muscles, it needs to be configured and fine tuned to reflect an efficient model. Examples of factors affecting a cloud implementation performance would be the number of Key Figures in an Integrated Business Planning (IBP) solution. The more Key Figures the higher the demand on the system and lower the performance.

 

Examples of common cloud performance challenges I have seen on SAP and Salesforce implementations are:

• Slow login time which is usually driven by network latency, demand on the enterprise SSO or other security system, firewall settings, or network device configurations.
• Dropped connections could be difficult to troubleshoot. On one implementation SAP users would receive a dropped connection error on an intermittent basis after about 30 minutes of being active on the system. Two weeks of troubleshooting uncovered the root cause of the issue was not due to the SAP cloud, but a misconfigured load balancer group of servers at one of the client's data centers.
• Initial load of templates, views and report runs are common issues when customers process large amounts of data. On a healthcare SFDC implementation the customer had a Contacts view for all its members, a whopping 1.5 million records. Obviously loading the view would take a few minutes of its agents staring at their screen. Educating the client on customizing the views to show members in a particular region, or who match certain filter criteria allowed them to view smaller data sets which were also more meaningful to their work.
• Refresh time is also a factor of the amount of data being retrieved, the browser
• Simulations
• Long running queries

 

Vendors constantly monitor their cloud operations checking memory utilization, background jobs status, CPU utilization, table sizes, system activities, and other performance KPIs to ensure optimum performance for their customers.

SAP key figure calculations can reach 10 million rows per second for its IBP solution in some implementations. Some factors that can affect that metric are data aggregations, projection, joins and uinions. In general loading a Planning View is dependent on the slowest Key Figure atomic calculation speed and the volume of data it processes. Using filters can sometimes be effective if it reduces the number of stored Key Figures that are defined as inputs to a calculation chain. However if filters do not affect the number of key figures and only affects data size the impact on performance might be minimal.

 

Are You Asking Your Engineer to Do the Impossible?

It is important for engineers building systems to understand how the organization will support the utility of their end product. I was asked to weigh in on a dispute between an IT vendor and a large multinational corporation. The vendor claims the IT security work has been delivered and they installed the systems and built the infrastructure needed. The IT sponsor at the corporation claims the implementation is not working.

 

Upon closer observation and after discussions with the technical team members I was able to identify the root cause of this confusion. Both entities were correct, the vendor indeed did deliver the work per technical spec, and indeed it was not serving the business objective the sponsor expected.


In a nutshell, the technical implementation was done correctly. However the way it was used by end users was not what both parties had envisioned causing certain portions of the solution to go out of sync with other components in the system, causing configuration errors yielding diluted value of the implementation. What was missing was an organizational policy that guides end users to follow certain process changes. Once the end users would follow the new organizational policy, and back doors were no longer allowed, the system components would be in sync and operate correctly.

 

The summary of this experience is that for a technology implementation to work properly the following need to occur in advance.

• Clearly articulate the updated operational process flow
• Ensure governance and policies support the new process flow
• Develop controls in the IT implementation to to enforce the policy

Without the three components the net realized value and user experience will be suboptimal. This is of course assuming all other standard best practices of system development have been followed from concept to deployment.

Closing on Poorly Contracted Projects

I was once asked to help with a large transformation program at a fortune 500 product development company. They had outsourced several IT security transformation projects to a vendor. The contract was very poorly written, more assumptions than deliverable were listed, the deliverables listed were not measurable and there was too much loose information. The projects which were supposed to take six months each ended up taking three years.

 

I was faced with one of two options, spending dozens of hours sifting through project change requests, meeting minutes and status updates for three years' worth of work, or come up with an agile, fair, and meaningful approach to close on the project. Luckily, I was provided a punch list that a former project manager in the past had felt was all the work items missing. The punch list helped me make the decision to choose the latter option and follow an agile approach to close out on the project. I followed some simple steps;

 

1. Setup weekly punch list calls
2. Defined my role and the objective of the effort
3. Went through the list each week
4. Compared to the original contract
5. Identified any gaps

 

These five steps might seem straight forward, which they are, except when you have two teams, one representing the client always asking for additional items which are mainly operational enhancements and not project deliverables; and another team which is the operational team on the vendor side fulfilling these requests, not realizing that they are also playing a role as the project vendor team. This is the crux of the complexity. It is not that the projects were not closed out, and not in production, they were indeed open projects, but the work delivered is well in production use for years, with new teams on board from both sides and now people are not considering the original baseline or expectations, they are comparing with the day before. It was a continuous bleeding scar for both companies.

 

So the trick in closing these projects in addition to the agile process above was assertiveness, clarity, separation of duties and the ability to act as a mediator and setting a clear measurable deliverable for each open item, with the confidence to act as a business analyst or contract manager specifying the measurable deliverable as needed on the go.

When its Time to Close a Project, Close it

It's in the best interest of the project, its sponsor, the team and the business to close a project when work is delivered and value is realized. I have come across several instances where the client feels the urge to keep the project open for one reason or another. Here are common cases where project teams keep the project open.

 

• Waiting for a new feature in a future COTS product release
• Few minor defects not fuly resolved
• Extra funds are available
• It will be hard to get approvals for a new project
• No guarantees that team members will be available in the future

 

None of these reasons are legitimate reasons to keep a project open. Open projects are like potholes, they only accumulate trouble until they get out of control and then need a complete removal and replacement with a new project. If the business value has been delivered, close it, move on and start a new one if needed when the time comes.

 

What is an IOT Platform

IOT Platforms come in different flavors and capabilities. IDC defines an IOT platform as follows:

 

• connects to and manages IOT endpoints
• ingest and process IOT data
• visualize and present IOT data
• builds and hosts IOT applications
• integrates IOT data into existing applications

 

Do you have a different definition?

I Received PMI Agile Certification This Week

This week I sat for the PMI-ACP exam and passed. It is a 3 hr 120 question examinations touching on several areas of the agile practice. As Certified Scrum Master, it required minimal preparation.

Do Not Shortcut the Instruments or Tools to Realize the End Product

This weekend I invited a close friend of mine to visit a nonprofit leadership center I oversee to give us some advice. He is a seasoned executive at a large retailer and supervises dozens of stores around the region. As head of the institute, and the main instructor my attention is usually drawn to compliance, curriculum and the overall performance of the organization. As he walked in he joined the trailing part of a financial reporting meeting and offered a couple of suggestions for a new program, we then proceeded outdoors to take a holistic view of the organization from outside. What comes next was very interesting.

He pointed out weeds on the sidewalk, and some stains on the building trim. Then he pointed out a few items that are not obvious to someone like myself who mostly focuses on the results and end deliverable. In other words he was able to make me realize that sometimes we get so entrenched in the mission or objective of the project; or we are operating on an agile framework delivering the next generation product while in the process the tools and artifacts used to get there are sub-quality.

Quite often on complex technology projects the team is busy delivering product value and checking off the deliverable list, while in the process they neglect the tools and instruments used to achieve those deliverables. For example the engineering team might produce a set of technical documents, however the document might not be totally polished like one that is being presented to the end user; margins might be inconsistent, different fonts on the same page, figures not numbered.

Agile project management should not mean producing internal PMO artifacts that have mismatched fonts or different font sizes, margins that look off, or a document that is lacking a table of contents. While it is true the client will never see these documents, and its only for the purposes of planning, but the fact that an instrument overall quality and aesthetics will eventually reflect the end product.

The lesson I learned is that a good balance across all areas of a project or organization is required. It is not enough to have a quality product, even if it sells well. The process in achieving the product also needs to be totally shiny and attractive even though the client is not paying for it.

Common Project Initiation Check Points

Businesses initiate projects differently, some places have long cumbersome tasks that need to be completed prior to kick-off a project. Others might be simpler. I share some common tasks that usually are required for a new PM to get through before she can have that first team kick-off.

Sponsor Funding Approval

This could also be referred to as appropriation request approval, budget allocation approval, capital investment approval or charter approval. Basically the sponsor signs off on a document that he has the available needs funds and specifies the total dollar amount of these funds. Some organization have set times when approvals are made and sent to the IT/PMO organization, in other cases it might be on an ad-hoc ongoing basis, where requests are queued up and processed by the IT/PMO organization at specific dates of the month or the quarter.

Resource Allocation Approval

This approval usually is made by the organization which is delivering the work. If it is an IT project then the IT group that will actually design, build and test the product or system being developed as part of the project charter. The fact that funding is available by the sponsor does not guarantee that the delivering organization has the capacity to work on the project during the period wished by the sponsor.

Technical Dependency Approval

This approval is usually obtained from the technical center of excellence, for example the enterprise architecture group, cloud center of excellence, security standards group or the group that is technically governing the organization's standards. A business might have the funds through a sponsoring organization to fund a project, and the delivering organization might have the resources (team, tools and supplies) to deliver, but there might be a major technical dependency preventing the feasibility of the project. For example in the case of an IoT enablement project, there might be a security identity management architectural pending problem, which the project requires resolution prior to going live. Another example in the transportation sector could be getting approval for use of certain material in paving roads to meet certain standards which has not been obtained yet.

Vendor Statement of Work Approval

Many projects depend on a third-party vendor to deliver the project. In order to initiate the vendor SOW process, all the above approvals might need to be secured. Other items that are common as well, are charge numbers by the Finance organization, Project ID number by the PMO and even in some cases names of lead resources such as the Project Manager, the Technical Lead and the Quality Lead.

Delivering Organization Statement of Work

The delivering organization usually would like to provide the sponsor with an internal SOW or charter that specifies the scope of work being delivered and any assumptions, dependencies and high level roles and responsibilities. This is different than the sponsoring organization
statement of work or charter which is discussed above and is mostly a guarantee that money is available to execute. The delivering organization is the one responsible for ensuring the project is delivered per specs. In some case the delivering organization does the work, or might outsource it to a third-party-vendor as discussed above. The delivering organization charter is the agreement between that organization and the sponsor. Whereas the Vendor Statement of Work is the contract between the delivering organization (prime contractor) and the third party vendor or organization (subcontractor)

In summary there are many organizational check-points that a project manager should be aware of when kick-off a project at a client or even internally for the employer. In large businesses, these approval points and processes are not always, or usually not in sync, and some might need to be in parallel.