Establishing a Project Management Office (PMO, sometimes called EPMO for 'Enterprise' PMO) within an organization can be a complex and challenging process. Some of the common challenges that organizations face when creating a PMO include:

1. Resistance to Change: One of the biggest challenges of establishing a PMO is resistance to change from employees and stakeholders. Some employees may not want to adopt new project management practices or may be skeptical about the need for a PMO.

Solution: To overcome resistance to change, organizations should clearly communicate the benefits of the PMO to all stakeholders and involve them in the process of creating the PMO. It is important to create a culture of change management that encourages all stakeholders to actively participate in the PMO creation process.

2. Lack of Resources: Creating a PMO requires a significant investment in resources, including personnel, technology, and training. Organizations may struggle to allocate the necessary resources to establish a PMO.

Solution: Organizations should develop a clear business case for the PMO that demonstrates the value it will bring to the organization. They should also allocate sufficient resources to support the PMO, including personnel, technology, and training.

3. Difficulty in Identifying and Prioritizing Projects: Organizations may struggle to identify and prioritize projects that align with their strategic objectives. Without clear guidance, it can be difficult for project managers to determine which projects to focus on and how to prioritize them.

Solution: Organizations should establish a clear process for identifying and prioritizing projects, and communicate this process to all stakeholders. The PMO should provide guidance and support to project managers in determining which projects to focus on and how to prioritize them.

4. Lack of Project Management Maturity: If an organization lacks project management maturity, it can be challenging to establish a PMO that can effectively manage projects and deliver value to the organization.

Solution: Organizations should assess their project management maturity and identify areas where they need to improve. The PMO should provide training, coaching, and support to project managers to improve their project management practices.

5. Resistance to PMO Governance: The PMO may face resistance from project managers who may feel that PMO governance is too rigid and inflexible, which can hinder project delivery.

Solution: The PMO should establish governance frameworks that are flexible and adaptable to the needs of individual projects. The PMO should also provide guidance and support to project managers in following the governance frameworks to ensure that projects are delivered on time, within budget, and to the required quality standards.

Establishing a PMO can bring many benefits to an organization, but it can also be challenging. Organizations must be prepared to address the challenges that they may face when creating a PMO. By implementing the solutions outlined above, organizations can overcome these challenges and establish a PMO that can effectively manage projects and deliver value to the organization.

A Project Management Office (PMO) is a centralized group within an organization that provides project management guidance, support, and oversight to ensure that all projects align with the organization's goals, vision, and objectives. PMO provides a set of standardized project management practices, tools, and templates that facilitate communication, decision-making, and project execution. Here are some benefits of establishing a PMO within an organization.

Benefits of Establishing a Project Management Office:

1. Standardization of Project Management Practices: One of the key benefits of establishing a PMO is that it provides standardized project management practices, tools, and templates that can be used by all project managers within an organization. This ensures consistency in the way projects are planned, executed, and monitored, which reduces the risk of errors, delays, and rework.

2. Improved Resource Allocation: PMOs can help organizations to better allocate resources by providing a clear overview of all ongoing projects, their status, and their priorities. This information helps organizations to make informed decisions about which projects to prioritize, which resources to allocate, and when.

3. Enhanced Risk Management: PMOs can help organizations to identify, assess, and manage risks associated with project delivery. This can be done by setting up a risk management framework, conducting risk assessments, and providing guidance on how to mitigate risks.

4. Better Communication and Collaboration: PMOs can help to facilitate better communication and collaboration between project teams, stakeholders, and senior management. This can be achieved through regular status meetings, project reports, and project dashboards that provide a transparent view of project progress and issues.

5. Improved Project Performance: Establishing a PMO can improve project performance by ensuring that all projects are aligned with the organization's strategic goals and objectives. PMOs can also monitor project performance and provide feedback to project teams to help them improve their project management practices.

6. Increased Project Success Rates: PMOs can increase project success rates by ensuring that projects are delivered on time, within budget, and to the required quality standards. PMOs can also help to identify and address issues that may impact project success and ensure that best practices are followed.

Establishing a PMO can bring many benefits to an organization, including standardization of project management practices, improved resource allocation, enhanced risk management, better communication and collaboration, improved project performance, and increased project success rates. These benefits can help organizations to achieve their strategic goals and objectives by delivering projects that are completed on time, within budget, and to the required quality standards.

Here are some interview questions that can be useful when hiring a software tester:

1. Can you describe your experience with software testing? What types of testing have you performed (functional, regression, performance, etc.), and what tools have you used?

2. Can you describe your experience with test automation? What tools and frameworks have you used, and what types of tests have you automated?

3. Can you walk me through your testing process? How do you plan tests, write test cases, and execute tests? How do you track and report on defects?

4. Can you give an example of a time when you found a critical defect in a software application? How did you discover the defect, and how did you work with the development team to resolve it?

5. How do you stay up-to-date with the latest trends and best practices in software testing? What resources do you use to stay informed?

6. Can you describe your experience with exploratory testing? How do you approach exploratory testing, and what techniques do you use?

7. How do you prioritize testing activities? What factors do you consider when deciding which tests to perform and in what order?

8. Can you give an example of a time when you had to work under tight deadlines? How did you manage your time and prioritize your testing activities to ensure that the software met its quality goals?

9. Can you describe your experience with performance testing? What tools and frameworks have you used to measure software performance, and what metrics do you track?

10. How do you work with other team members, such as developers and product managers, to ensure that software meets the requirements and quality goals? What strategies do you use to communicate and collaborate effectively?

These interview questions can help you assess a candidate's experience, skills, and approach to software testing, as well as their ability to work effectively with other team members and adapt to different situations. You can also ask follow-up questions to get more detail and context around a candidate's responses.

The software development life-cycle (SDLC) is the process of planning, designing, building, testing, and deploying software. There are various models for the SDLC, each with their own advantages and disadvantages. Here are some of the most common models:

1. Waterfall model: The waterfall model is a linear, sequential approach to software development, where each stage is completed before the next one begins. The stages include requirements gathering, design, implementation, testing, and maintenance. This model works well for projects with well-defined and stable requirements, but can be inflexible and slow to respond to changing requirements.

2. Agile model: The agile model is an iterative and incremental approach to software development, where software is developed in short cycles called sprints. The stages include planning, requirements gathering, design, implementation, testing, and deployment, and the process is repeated in each sprint. This model works well for projects with evolving requirements and a need for flexibility, but can be challenging for teams that are new to agile methodologies.

3. Spiral model: The spiral model is a risk-driven approach to software development, where risks are identified and addressed in each stage of the SDLC. The stages include planning, risk analysis, design, implementation, testing, and deployment, and the process is repeated in a spiral fashion as risks are identified and addressed. This model works well for projects with high levels of complexity and uncertainty, but can be time-consuming and expensive.

4. V model: The V model is a variant of the waterfall model that emphasizes testing and verification throughout the SDLC. The stages include requirements gathering, design, implementation, testing, and maintenance, and the testing process runs in parallel with the development process. This model works well for projects with a strong emphasis on testing and verification, but can be inflexible and slow to respond to changing requirements.

5. DevOps model: The DevOps model is a collaborative approach to software development that emphasizes the integration of development and operations teams. The stages include planning, development, testing, deployment, and monitoring, and the process is highly automated to enable rapid and frequent releases. This model works well for projects with a need for rapid release cycles and a high degree of automation, but can be challenging for teams that are new to DevOps methodologies.

Each of these models has its own strengths and weaknesses, and the choice of model will depend on the specific requirements of the project, the experience and preferences of the team, and the organizational culture. Successful software development requires careful planning, effective communication, and a willingness to adapt to changing requirements and circumstances.

The PfMP Exam is for senior executives who have reached a point in their career where they are part of the council within an organization that decides which projects get funded next. The PfMP is short for Portfolio Management Professional, and is a certification offered by the Project Management Institute (PMI).

Once you've met the criterial for experience and training, you must submit an application detailing your experience, to be reviews by a board of existing PfMP holders at PMI.  This is a challenging process and often applications are rejected.

The rejection letter appears to be somewhat vague, and is actually a standard form-letter. Something a bit confusing is that because it is a rejection form-letter, the reasoning given in it is not always accurate.

What the board is looking for are details of your portfolio (size, types of outcomes, projects, programs), and also what you did to establish the PfMP process, if it did not already exist, and what you do to govern it.  How often you mmet with the portfolio committee, etc.

Portfolio Management is critical within a company because organizations grow through projects.  Project spending actually sets the strategy for a company.

Mike Berry, PMP, CSMC, CSPRO, CSM, CSPO, PBA, ACP, ITIL, CSM, etc.
www.RedRockResearch.com

The ISTQB-CTFL (Certified Tester Foundation Level) curriculum details 5 levels of testing, 4 test types, and 3 testing approaches.

The five levels of testing are as follows: Component Testing, Integration Testing, System Testing, User Acceptance Testing, and Maintenance Testing.  They are missing a needed sixth level, Smoke Testing. Perhaps one day they will add it.  Here is a description of all of them.

Smoke Testing: A quicks run through of all of the screens and reports within a system to ensure the developers gave you everything.  This ensures you don't get 2 days into testing a large app only to discover a ".dll not found" error due to the developers not including everything in the install package. Smoke testing should take now longer than 20 minutes or so.  Two added benefits once an organization has smoke test in place is that the implementation team can use the smoke test to test a new install, and if a production system goes down and is brought back online a smoke test and ensure all of it was brought back online.  But, I digress....

Component Testing: Checking each component of a system. There are 5 types of comports in software: 1. Screens, 2. Reports, 3. Interfaces, 4. Logic Modules, and 5. Data Structures.  Typically, component testing in software is checking each screen, and each report. The interfaces are tested at the next level.  While screens and reports are tested using requirements-based "black-box" testing, logic modules are best tested using "white-box" tools like logic trees and logic tables.

Integration Testing: There are two types of integration testing.  Internal integration testing is testing module to module (screen to report, for example).  External integration testing is testing system to system (your app to Paypal interface, for example).

System Testing: The best way to system test an app is to create a set of "typical day in the life of a user" flows representing different ways a user would use an app.  Providing all of the previous test levels worked reasonable well, system testing is a way to ensure everything is working together.

User Acceptance Testing: Once the system has been tested enough that the release success criteria has been met, the system should be shown to a real end-user for a final approval.  This should not be a surprise to the end-user.  In a healthy environment, the end-user should have been working closely with the development team as the software was created. Since the product should match requirements, any changes at this point would require updated requirements, and likely a new work order.

Maintenance Testing: This type of testing is used after an OS updated, or database change, or some other type of refactoring has occurred.

The Four Test Types found on the CTFL Exam are:

Functional testing (Black-box Testing): Requirements-based testing. When you cannot see the code, but all you have is a set of requirements, or user-stories. This is traditionally what people think of when they envision testing software.

Non-functional testing: Non-functional requirements are "implied" requirements which apply to the entire software app.  For example, security requirements, or HIPAA requirements, or PCI requirements.

Structural Testing (White-box Testing):This is used for component testing logic modules, where the developer share the code with you, and together you create flowcharts, logic trees, and logic tables.

Change Testing: This testing happens after a bug is found and the software is sent back to the developer, and the developer fixes the bug and returns the updated app to be tested again.

The Three Testing Approaches are:

Black-box Testing: For testing components with requirements, such as screens and reports. 

White-box Testing: for testing components where you can see the code, like logic modules.

Ad-hoc Testing: for testing an app when no requiems are present.  This can be due to time constraints, or perhaps you were just given an app and have to learn about it to create an approach and set of test plans to test it adequately.

In August of 2021, PMI released the PMBOK 7th Ediiton.  I have a previous post describing what's new. Surprisingly, is a book filled with professional soft-skills, and not really a process-guide for executing projects.  Wihile PMBOK 1-6 Editions contain step-by-step process guidance for project execution, PMBOK 7 is all about the soft skills.

I tell my PMP and CAPM students they will need both, and an easy way to think about it is to use PMBOK 6 for learning how to manage projects, and PMBOK 7 for learning how to be an excellent project manager.  One analogy I used in a recent public presentation is that PMBOK 6 is the bones, and PMBOK 7 is the meat.

Mike Berry  Red Rock Research

I've been instructing students on the ISTQB-CTFL Certification curriculum for a number of years now.  I like to tell students the CTFL program is really a mini project-management training program.

Somebody hands you a software app to test, what do you do now?  You decompose the App in to smaller portions which make sense to you, constructing a Work Breakdown Structure.  Then you identify items to test within the WBS, organizing them by Test Plans. They you prioritize all test plans into a Test Execution Schedule so and your test team will know in what order to perform the tests.

You'll keep track of test coverage, and results, reporting on progress as you work through the app. Here's where it's important to communicate with your developers thoroughly so they can fix bugs you find and get the updated app install back to you for confirmation testing.

finally, when your testing matches the success criteria, you'll report of the final results of your findings and wrap up the testing project, adding lessons learned, estimates vs. actual, and other information into a test historical repository.

All of these activities are the foundation for project management.

In August of this year (2021), the Project Management Institute will release PMBOK 7!  This edition will be different than past editions of the PMBOK as PMI is emphasizing a descriptive program versus a prescriptive program.

The new Project Management Body of Knowledge will contain 12 Project Management Principles, which help guide decisions, 8 Project Performance Domains, and 7 Model Sets.  They are as follows:

12 Project Management Principles:

• Stewardship
• Team
• Stakeholders
• Value
• Systems Thinking
• Leadership
• Tailoring
• Quality
• Complexity
• Risk
• Adaptability and Resilience
• Change

8 Project Performance Domains:

• Stakeholders
• Team
• Development Approach and Life cycle
• Planning
• Project Work
• Delivery
• Measurement
• Uncertainty

7 Model Sets

• Situational Leadership
• Communications Models
• Motivation Models
• Change Models
• Complexity Models
• Project Team Development Models
• Other Models

Employee motivation is an ever-present concern for most proactive managers.  Interestingly enough, motivation can come from both functional and dysfunctional sources.

I've seen employees motivated for many different reasons: recognition, financial incentive, empowerment, personal growth, tension release, fear, and finally there's that weird Lord of the Flies thing where employees get motivated together against another employee.

In their book, Motivating Employees, Anne Bruce and James S. Pepitone describe the most effective ways to motivate a team.  They describe the three C's which are vital to functionally motivating employees:

1. Collaboration: Be sure to involve employees in decisions and discussions where their efforts are involved.

2. Content: As they produce suggestions, act on those suggestions immediately.

3. Choice: Be sure to offer choices to your employees--even if you can predict what they will decide.

These three techniques actually empower your employees.   Involving employees in decisions that affect them, or the outcome of what they are working on produces a level of buy-in that is hard to match any other way.

Bruce and Pepitone continue with an examination of Theory-X and Theory-Y motivation and management styles.  These styles were originally presented in the 1960's by Douglas McGregor.

McGregor states that Theory-X managers proceed from the assumption that their employees are uninformed, lazy, and needy of high-structure.

Theory-Y managers, however, proceed from the assumption that their employees are qualified, intelligent, and capable of making proper decisions provided they are given proper goals, accountability, authority, and resources to accomplish their tasks.

Although Theory-X is the most effective approach during some situations, if you consider the amount of college-educated employees in the workforce today, it's easy to see how Theory-Y, if applied properly, yields much higher performance.

The authors continue with a formula for encouraging Entrepreneurial Thinking.   Their five-step formula is:

1. Explain the organization
2. Demonstrate how the organization operates and generates income
3. Help your employees understand the competition
4. Encourage intelligent risk-taking
5. Inspire innovative thinking

Another great idea the authors present is to link motivation to performance.  They suggest you develop a written-list of performance standards for meeting and exceeding the expectations you've agreed upon during collaborative sessions with them.

The authors talk about how important it is to weave fun into everything your organization does.   This may sound like a unusual suggestion at first, but the authors point out that there is a direct correlation between fun on the job and employee productivity, moral, creativity, satisfaction, and most importantly--retention.

The final few chapters in the book discuss de-motivating factors (or individuals), and how to deal with them.  There is also a good chapter on conducting effective employee-reviews.

Overall I recommend this book to any manager.   It's a great book to re-read every so oft r/>
Mike J. Berry
www.RedRockResearch.com