Each year, there are new trends in project management. I wanted to weigh in with a few of my thoughts on what they might be this decade.

1. Beyond the triple constraint 

Organizations have been looking to have a good mix of project, program and portfolio managers. Organizations should re-design and build project management systems thinking beyond the triple constraint.

The combined power of project portfolio, program and project management enables delivering business results not limited to the triple constraint.
For example, if a project was delivered on time, within budget and with required quality, but the project outcome doesn't provide expected value, then in my opinion, the project should not be considered successful.

As such, it behooves project managers to expand his or her career growth to acquire new skills and experience in the areas of program management and portfolio management.

2. SMAC project management
Due to the emergence of new projects in the social, mobile, analytics and cloud (SMAC), organizations must make sure their project management approach includes new or refined project lifecycles, templates, checklists, best practices, lessons learned, estimation techniques, risk registers, etc.

Organizations must train project managers to prepare them for managing these SMAC projects by educating them on these trends and how (or if) they will affect them.


3. More projects, different business functions 

Projects will start to be identified in different business functions where they might not exist very often, such as sales, marketing, alliances, human resources, etc. Marketing managers, sales managers, HR managers, finance managers and the like have to acquire project management skills to deliver better results in their respective functions.
 
Organizations should refine their project management strategy to include project lifecycles for all projects and training for all managers. Project Management Centers of Excellence (COE) have to focus on creating special learning assets to train managers on project management in other functions.
 

4. 'Project-ized' education 

In academics, course curriculums will be increasingly 'project-ized.' An engineering course, for example, could have more than 40 projects in the span of four years. Implementing those projects will enable students to learn through multiple and cross-discipline subjects. Students could look back on all of the projects in those years as a "project portfolio."
 

5. Every employee is a project manager

Project management means having a mindset of systematic planning, execution, monitoring, controlling and closure. Every task should be considered as a tiny project.

For example, writing a software code as part of a larger IT project should be considered a tiny project. Project management principles will be applied to successfully deliver the code on time and with high quality.

Creating this mindset across an organization requires cultural change. In many organizations currently, only a few people focus on project management. With the practice of considering every task as a tiny project, the need to have 'self project management' becomes prominent.

The best way to train employees to think like project managers is through on-the-job training. Teach employees to create mini-work breakdown structures, mini-schedule, self-reviews and corrective actions.


6. Project entrepreneurship 

Project entrepreneurship means project managers must develop an "entrepreneurial" mindset. This enables project managers to take on risks, foster innovation and focus on business value rather just looking at the traditional triple constraints.


7. Program management offices (PMOs) as profit centers

PMOs will be transformed from cost centers to profit centers. PMOs will build very high-end consulting skills and offer services to business units on a profit basis. PMOs will focus on an 'outside-in' perspective and move away from an 'inside-out' perspective. PMO drivers will be around customers, markets and the economy, and not just limited to internal efficiencies
.

This means that project managers have to understand the outside-in perspective. They have to focus on outcome and the value to be delivered to customers.
 

In a traditional lessons learned session that is conducted face-to-face, project managers know each person who is present and his or her role on the project.

But technology today affords us the luxury of being able to do many things online -- such as holding a lessons learned session. We can engage with people across the country or someone who may be sitting right next door. Regardless of where someone is located, we must maintain a cordial and professional manner when we interact online.
 
When you have dispersed project teams -- and even sometimes otherwise -- getting people to stay focused and not be disrespectful to others in a lessons learned session is a challenge.
 
To overcome this, set the rules for participating in the session. Make sure participants understand them and agree to them. These rules should include:

• Respect. Allow someone to make his post without experiencing sarcasm, blame or degradation. Emphasize open, honest and polite communications. Project team members will develop an appreciation for each other, the project manager and their organization.
• Treat people as if they are right next to you. Use a tone of courtesy that can be recognized in any language. Respect the person's time and keep posts brief. Do not veer off on other conversations -- stick to the discussion.
• Put a face to a name. Many applications allow photo uploads. When someone responds, everyone can see who is participating in the discussion.  

Setting the right tone in these sessions can lead to so many other opportunities. For example, when good feelings are engendered, it helps to build your team and other business relationships. You can learn more about each person, such as associations they may belong to or networking contacts that you can use for future collaborations and project guidance.
 
When you maintain control of the meeting and employ general courtesy, it keeps the discussion flowing and ensures everyone gets the information needed about lessons to be learned.
 
How do you maintain control in lessons learned sessions?

The structured approach of project management can add value to operational IT departments. What makes this work is the approach that the project management office (PMO) or the project management team defines in its project management methodology for release of the systems into production environments.

Operational departments should execute with a process often referred to as "steady state transfer." This process gives the project team the opportunity to validate all the key production processes such as the support, maintenance cycle, systems restore and sanity testing, which is the basic testing of the system functionality.

Project teams launch the steady state transfer after successful tests show the systems are ready to be released into the production environment.

This validation step -- to ensure that the system processes are well mapped between various support departments -- adds value to the operations teams. The validation step is done during project execution using the steady state transfer process -- and without generating special projects.

This validation step in the project management practice guarantees process interface manuals are updated with any changes to the processes and the test results.

The operational departments work with the project team to complete this task and thus make a smooth transition into the "steady state" of operation.

What processes does your organization use to achieve the same results?

See more posts on IT.
Read more from Dmitri.

Project management plays a vital role to successfully deliver IT services to customers. Each IT service -- from strategy and consulting to platform migration -- has its own life cycle and project managers must be aware of the different phases, tasks and deliverables. This means IT services organizations must be dedicated to build qualified and competent project managers.

Career paths in project management help build the competencies in project management in an evolutionary manner. Career paths also provide a clear road map for the growth of the employees in the profession.

Those IT organizations that invest on designing the project management career path and relevant skills of the employees deliver excellent business value to customers.

In my opinion, there are nine "levels" of careers in IT services organizations. Titles depend on the organization, but in my experience, these are the levels:

Level 1: Entry-level employees with either a technical education background or a functional background may have titles such as software engineer or functional analyst.

Level 2: Employees at this level participate in requirements or business process analysis, high-level design, and technical specifications.

Level 3: This could be the team leader level. He or she might manage a team of three to four members and deliver part of project deliverables.

Level 4: This could be the project leader. He or she might manage a team of about 10 members and deliver small projects.

Level 5: This would be the project manager. He or she manages a team of 20 to 30 members and delivers multiple, medium-size projects or a large project.

Level 6: This is the senior project manager level. He or she manages a team of about 100 members and delivers multiple large projects.

Level 7: This is usually the program manager level, managing a team of about 200 people. He or she delivers complex program(s) for a single customer.

A delivery manager could also be at this level, managing a delivery unit with a team of 200 members. He or she delivers logically grouped projects based on technologies, customers, verticals or regions. For example, a delivery unit could consist of projects from different customers in the Middle East region.

Level 8: Usually the head of delivery, he or she delivers multiple complex IT programs or manages multiple delivery units.

Level 9: This is the chief delivery officer. He or she takes the responsibility of overall delivery of IT organization.

To move from one level to the next in the project management career path, it requires improving current competencies and learning new competencies.

To move up the career ladder, project managers should focus on the nine knowledge areas from A Guide to the Project Management Body of Knowledge (PMBOK^® Guide).

They should also study The Standard for Program Management.

In addition, core competencies should include, but aren't limited to:

•    Project life-cycle management
•    Effort management
•    Software change management
•    Configuration management
•    Organization change management
•    Leadership skills
•    Multi-cultural team management
•    Global delivery model

Do you agree with these career levels? What skills should project managers focus on to move up the IT career ladder?

Editor's note:  PMI's Pathpro^® is an online tool that organizations and practitioners can use to identify the skills and competencies needed to create a successful project management career path. 
 

Many of today's agile project teams are distributed around the globe. While simple implementations of agile processes assume co-location, in larger enterprises, this is rarely the case. Selecting tools to assist remote communication helps, but it's not enough.

Here are some human factors to consider, beyond the tools, to work successfully with a distributed team:

Cultural differences can become apparent when working with global talent. Some people are uneasy if some social small talk is omitted as part of doing business. Some are uncomfortable if we don't simply get to the point. This affects agile teams as they implement practices such as self-organization, pair programming, and retrospectives. Remember people's assumptions can vary.

Time-zone differences can be helpful by providing longer hours of coverage. But check with your teams on when they begin and end their workday. Different cultures have different laws and traditions on when to go home. Not all people have private transportation, and not all countries use daylight savings time.

Finding teams in compatible time zones can be an advantage with more hours of coverage, if the hours and needs are remembered. Partnering with teams that are north or south of each other makes this easier because the time difference is less extreme.

Communication differences among distributed teams also require forethought. Agile teams will notice a need for engaging and informative tools in their story grooming, estimating, planning and retrospective meetings.

Telephone calls can be awkward because there is no visual cue as to who is speaking and no person to look at. Also, sound varies for each person depending on if they are in the same conference room, on a speakerphone, using a headset or cell phone. Make it a point to include people on the phone if part of the group is face-to-face.

Video conferences or webcams might be a better option. Be aware of the background so it is not distracting. Also be aware of the lighting quality and direction -- illuminating an attendee's face is better than a dark silhouette.

Spatial user interfaces, which extend traditional graphical user Interfaces by using two or three-dimensional renderings, give people someone to look at and allow positional body language and gestures to convey nonverbal information. However, be sure to allow training time for participants so they can make the most of these environments before needing to concentrate on a meeting.

By using the right tool and having the right mindset, agile teams can work together across wide distances.

How do you work successfully with distributed teams?

The first global delivery model (GDM 1.0) was created a few decades ago to reflect the outsourcing and offshoring of IT services, mostly in India. A global delivery model is typically a method of executing a technology project using a team that is distributed globally.

Now, there are many choices in terms of outsourcing, and technology plays more of a role in project communication. As such, GDM 2.0 is on the horizon. And project managers must reorient themselves to the changed environment of cloud, social and mobile computing.

I would describe GDM 2.0 as "intelligently distributing the project's work, team, leadership and governance across multiple locations and leveraging technology to provide high-speed, high-quality and low-cost solutions to global customers."

A few of the tenets that contribute to providing customer value using a GDM 2.0 are:
 

• Reduced cost: Executing projects at low-cost locations spanning multiple countries, cultures and languages

• Abundant talent: Accessing talent across different locations

• Follow the sun: Leveraging time-zone differences to maintain continuity in managing projects

• Quality of service: Using best practices, lessons learned and standards to provide faster, better, cheaper and steadier services

• Knowledge and collaboration: Implementing robust knowledge-management systems to help build a seamless flow of information across multiple teams, projects and locations

• Continuous learning: Using ongoing training to prepare project professionals for the market, customers and projects

Here are a few of my thoughts on the future of GDM 2.0:
 
1. Almost all IT service providers are now building their own private clouds, making the provisioning of IT resources faster and cheaper. In the past, project managers had to wait for weeks or months to get certain IT resources.
 
2. IT service providers that develop applications using platform as a service (PaaS) and that implement package applications using software as a service (SaaS) now involve cloud providers. Project managers must be aware of the various risks, contractual obligations, security issues and potential legal issues of working in this multi-party environment.
 
3. IT service providers are building process platforms that leverage cloud infrastructure. That means project managers must learn to work with competitors, as customers might select process platforms from multiple IT service providers.
 
4. Mobility in project management will be a norm in the GDM 2.0. IT service providers have to mobilize their project management, software engineering and other critical governance processes to improve project performance. These service providers will need to make investments to rebuild their project management tools and applications to work on mobiles or to procure mobile project management applications.

What do you think the future of GDM will hold?

See more posts on project communication.
 

In my previous post, I said, "I can't be sure but I have a feeling that the nature of the project management game is changing." I'm becoming more certain of that all the time -- especially in terms of what that means for my career.

Recall that I articulated three trends that "give me pause:"

• Project management jobs are following other IT jobs to emerging markets
• Agile is gaining in popularity as a way to approach IT projects
• The way the global economy functions is said to be changing

Each of these injects a fair amount of uncertainty into my career plans.

In a project context, uncertainty is interesting in that it has the potential to positively or negatively affect project objectives. The same is true of career objectives, which makes those three trends very interesting to me.

So what are my career objectives? Simple:

1. Continue to manage projects
2. Have enough variety in those projects to keep things interesting

To what extent might the aforementioned trends affect those objectives? It depends on the timeframe. Thinking about the state of the profession over the next four or five years, two questions come to mind:

• Within that time, what is the likelihood that one or more of the three trends I outline will have an impact (positive or negative) on my two career objectives?

• What might that impact be?

You tell me.

What are your overall goals for the next five years, and how will the shifts we see in project management affect those goals?

Generally, an IT project schedule is divided into three phases: 30 percent requirements, 40 percent coding and 30 percent testing. But have you ever noticed that in the coding phase, 60 percent of the effort goes into unplanned bug fixing?

I read somewhere that in the software industry, 90 percent of the tasks take 10 percent of the time, while the other 10 percent take 90 percent of the time due to rework. If as a project manager you can control this rework effort, I am sure that your project will be successful in terms of profit value, customer satisfaction and team motivation.

The project I am currently working on is no different. We had the same rework problem. So based upon data analysis from the last 4 to 5 months, the team came up with a list of preventive actions that will help us in reducing rework.

But I was still looking for something to keep them motivated to avoid rework. I prepared a logo and it was pasted on all desks.

 

What do you say, is it going to help us?

My company is currently in the midst of delivering software that will help revamp our enterprise measurement program. In a way, we are defining the standard to which our software development projects will be graded on.

Here are some of the measurements we are interested in:

Product fault density
Requirements volatility
Defect containment
Development productivity
Hours per defect
Software size growth
Engineering percent rework
Action item aging
Risk and opportunity tracking
Earned value management systems measurements such as cost performance indicator and schedule performance indicator

The benefit of having a set of common measures for our business is quality product deliveries--which translates into increased customer satisfaction and ultimately improves the bottom line.  

Take for example the measure of fault density. This is a lagging indicator to measure the quality of the software product after the development effort has completed. This is measured in terms of 1,000 logical source lines of code (KSLOC). This measure is calculated as:

        Number of Defects/ KSLOC

The data are compared against organizational thresholds. Root cause analysis on the variance can point to issues with software complexity and insufficient/ineffective test life cycle. Keep in mind that having meaningful thresholds calibrated for your organization is the key to ensure you don't waste your time with needless analysis.

With that said, what measures do you consider important to your business?

I work with an IT software development organization, so most of my posts are specific to software development projects. During the testing phase, we typically experience the following problems:

1.    We expend approx 15% to 20% of the development effort in the bug-fixing phase.
2.    Our team discovers a lot of missing functionality during the testing phase.
3.    Quality assurance (QA) and development teams have different mindsets, so they understand the same feature in different ways.
4.    Test cases written by the QA are a conversion of a software requirements specifications document into an excel format.
5.    During and after the coding phase, the developer doesn't often test the application himself and instead leaves everything for QA. He tends to believe bug identification is QA's task and that the developer should only be responsible for fixing bugs.
 
    I think the software testing cycle works on the 90:10 rule: Ninety percent of the project takes 10% of the allocated time, while the remaining 10% takes 90% of the time. After expending a lot thought on this process, we came up with some solutions that may reduce the testing and bug fixing cycle:

1.    Let the QA and development teams both review the requirements and get necessary clarifications from the client.
2.    Ask the developer to give a presentation of his project understanding to QA and his module lead.
3.    Have QA prepare the test cases.
4.    Ensure test cases cover the functionality as well as the user cases and scenarios
5.    Have the developer review and log defects, too.
6.    After the completion of the coding phase, ask the developer to run high priority test cases prepared by QA.
7.    The developer should submit the test log to QA.
8.    QA shall start the testing.
9.    Each discovered bug should have a corresponding test case ID. If the test case doesn't exist for the bug, then QA should add a new test case for it. This will ensure the test cases have covered all the use cases.
10.    In the test log for each failed test case, enter the bug ID. This will ensure all bugs are raised and tracked to closure.
11.    Perform the Root Cause Analysis (RCA) for each bug and improve the coding process.
12.    Track the bugs raised by QA versus the bugs raised in user acceptance testing or bugs raised in production.
13.    Test cases should be data-oriented, and QA should be trained enough to write simple SQL (Structured Query Language) queries.
14.    The test log should show the number of rounds executed with the number of test cases that have failed, passed or have not been executed for each round of testing.
15.    Track the actual effort spent in the testing and bug fixing phases to better plan for the next module or project.