Tag: Project Management

OUTSIDE THE BOX Forum: Mastering the 10 Challenges to Agile Portfolio Management

Written by Robert Wysocki on November 14, 2017. Posted in Articles. 4 Comments on OUTSIDE THE BOX Forum: Mastering the 10 Challenges to Agile Portfolio Management

Agile projects are those whose goal and or solution are not clearly defined. These projects dominate the project landscape.

Usually some agile or extreme model is used to manage them. They are high risk, high change and their outcomes are not at all certain. Managing portfolios of these projects is very complex and will challenge even the most experienced among us. In priority order the major challenges are:

Organizational support
Project governance
Measuring performance
Meaningfully involving clients
Structuring the project team
Estimating business value
Eliciting requirements
Scheduling constrained resources
Improving process design
Improving product design

This article describes each challenge and offers strategies for dealing with each one.

ORGANIZATIONAL SUPPORT

Organizational support extends from the very highest management levels in the organization all the way down to the project sponsor and the management team to whom the project manager reports. A Project Support Office (PSO) should be in place to offer not only the vetted processes and practices that are needed in an agile environment but also the training and consulting support that a complex project manager and team might require in the discharge of their responsibilities.

PROJECT GOVERNANCE

Complex projects are high risk projects. To mitigate some of that risk decisions should be made as close as possible to the expertise for making those decisions. That responsibility should be assigned to the team. But not just any team. The only decisions that should be made above the team level would be those decisions to adjust priorities, postpone the project or terminate the project.

MEASURING PERFORMANCE

The one common thread that links all projects is the business value that each expects to bring to the client and the organization. Business value would have been the deliverable that was used to approve the complex project and its plan. That might seem like the problem has been solved. Don’t be too quick to judge however. There is much yet to be done. Project performance is the variable that we will use to compare each project, program and portfolio in the enterprise portfolio. That comparison will be used to decide project status for the coming iteration. So we have to include not only past performance but also the prospect for future performance.

MEANINGFULLY INVOLVING CLIENTS

In the traditional project world clients were involved at the requirements elicitation phase and after that only for status reporting and deliverables approval. In the complex project world that is no longer effective. In its place the client must be meaningfully involved even to the extent that they will have management and decision making authority as members of the project team. They are the product experts and will have responsibility for managing the deliverables. The process expert on the team is the traditional project manager. They and the product manager have co-equal management responsibilities for the project.

Advertisement
[widget id=”custom_html-68″]

STRUCTURING THE PROJECT TEAM

To be most effective a complex project team should count among its members those who possess all of the skills and competencies needed to succeed. That includes the decision making needs of the project. The project team template is shown in Figure 1.

Figure 1 ECPM Project Team Template

For a detailed discussion on the Co-Manager Model see Strengthening Client Involvement in the PRINCE2 Process Using the ECPM Co-Manager Model, (PM Times Oct 24, 2015 and PM Times October 28, 2015).

ESTIMATING BUSINESS VALUE

Every project is approved based on the business value it is expected to deliver. In the complex project world the solution is usually not completely known at the outset and must be discovered through iteration. That makes the expected business value that will be delivered very difficult to estimate. As iterations proceed the estimated business value may be different than the expected business value of an acceptable solution. The estimated business value that a project will deliver is often the primary factor underlying approval of the project business case. In a complex project that is seldom more than a best guess. As the project work commences and the solution begins to take shape that estimate is revised. It can change and so can the priority of the project.

ELICITING REQUIREMENTS

In the complex project world it may not be possible to elicit complete and clearly defined requirements. This step is designed into the ECPM Framework. The design is a two-step process that totally eliminates the current problem of incomplete requirements. The first step is a high-level identification of the set of necessary and sufficient requirements for achieving the expected business value delivered by an acceptable solution. How these requirements will be met is left to the second step. The second step is relegated to the iterations and stages of the framework. For details see A Fresh Look at Requirements and Requirements Elicitation in Complex Projects (PM Times, July 28, 2014)

SCHEDULING RESOURCES

If all active complex projects are identified within a portfolio the problems associated with resource scheduling are somewhat reduced. Unfortunately that situation rarely exists. Instead a number of projects that are defined and staffed within a single business unit are not part of any portfolio. While that may be true of a project it isn’t necessarily true of the resources that staff these “below the radar” projects.

IMPROVING PROCESS DESIGN

Complex projects don’t seem to follow any predictable process. Each project presents the team with a unique set of circumstances and challenges them to respond accordingly. That is why the ECPM Framework includes a continuous process and product improvement program. Figure 2 is the continuous process improvement program that has been integrated into the ECPM Framework.

Figure 2: The ECPM Framework continuous process improvement process

In time the organization will build a comprehensive collection of responses.

IMPROVING PRODUCT DESIGN

Figure 1 has also been integrated into the ECPM Framework but adapted to product improvement rather than process improvement. The Probative and Integrative Swim Lane process is the heart of that product improvement effort. It is unique to the ECPM Framework and will not be found in any other project management process.

IN SUMMARY

The ECPM Framework was designed with these challenges in mind. Most of the challenges are mitigated through ECPM Framework design features (Project governance, Measuring performance, Meaningfully involving clients, Structuring the project team, Eliciting requirements,

Scheduling constrained resources, Improving process design, Improving product design). Others are mitigated through the execution of the complex project.

How all of this happens requires a book length discussion and is out of scope for this article.

Innovation and The New Stakeholders

Written by Leonardo Chaves on November 7, 2017. Posted in Articles. 3 Comments on Innovation and The New Stakeholders

In today’s world, the question is not whether or not to be innovative, but to what degree or stage.

Organizational Structures and / or individuals’ arrangements for conducting innovation processes are a form of communication of the company regarding the level of priority and strategic importance that these elements occupy. The stakeholders of innovation projects may include educational institutions, ICT’s basic industrial infrastructure, technology companies clusters, suppliers, users, innovation systems, government, financial markets, legal systems, development agencies, business systems, among others. Added to this is the example of the industrial revolution in which the political and economic environment were factors in encouraging innovation.

In general, project management methodologies deal with stakeholder management. The PMBOK 5ed. It presents a set of identification, planning, management and control of the level of stakeholder engagement. The SCRUM reinforces the importance of the relationship between the stakeholders with frequent meetings. Prince2 underscores the importance of your engagement. Particularly in the field of innovation, stakeholder engagement and engagement (fully identified) is critical to project success.

The innovation depends on the technological capacity of the organization. The technological capacity is related to a set or stock of resources based on technological knowledge. Often companies derive mechanisms of technological learning. The form and speed with which companies build and accumulate technological capacity directly impacts on their competitiveness. Some questions are relevant in the assessment of technological capacity and innovation:

Where are we in terms of technological capacity?
How long does it take to get here?
How long are we “stationed” at a given level of capacity for a specific technological function?
How far are we from the technological frontier?
Where do we want to be until year x?
What are the resources and how do you manage them to reach a level of technological capacity in x years?

Technology capability and technology are developed within specific organizational contexts. The more complex the more difficult it is to imitate it and copy it – the source of competitive advantage. In the context of developing countries, human capital and organizational capital have greater relative importance than technical systems. According to Temaguide, “Technology Consists of knowledge and experience as well as equipment and facilities. It is software as well as hardware and it is services and systems as well as products and processes. Technology uses ideas, creativity, ingenuity, intuition, intelligence and foresight. “
Innovations in organizations can be analyzed in three dimensions: macro, meso and micro. The macro dimension refers to Short-term Indicators, S & T & I Policies, National / Regional Innovation Infrastructure, Innovation Systems, Cooperation Networks, Technological Regimes and Sector Systems, Financing Innovation (Public and Private) and the Socio-Cultural Context. The Meso Dimension is related to the Innovation Strategy, Institutional Guidelines for ICTs for Innovation, Innovative Business Models, Innovation Projects Portfolio and Organizational Structuring for Innovation. The Micro deals with Innovation Projects, the Construction of competences – individuals and groups, Technological Learning, Entrepreneurial Behavior, Financial Management of innovation.

Advertisement
[widget id=”custom_html-68″]

The organizations are immersed in contexts that act as conditioners of the innovative activity. For this, companies must take into consideration the market, the solutions, the commercial relationships, the consumer experience, among other aspects. Innovation also differs among industrial sectors (Tidd et al., 2008).

A sectoral competition pattern presents its own structural characteristics:

Intensity of competition;
Degree of concentration of production;
Entry barriers;
Exposure to international competition;
Regulation.

Companies demand funding for their innovation projects because of the inherent risk of these activities. Investing in development and market testing is still needed to mitigate risk. Many projects must demonstrate the impacts they can bring to the development of the business.

Investment patterns and the influence of capital differ between sectors. The key factor can be related to the understanding of internal processes and the innovation model (Stage-gates (Cooper, 1993), Clark & Wheelright, Pentathlon (Goffin and Mitchell, 2010), Hansen and Birkinshaw (2007), Docherty ))

The innovation model can also determine the inclusion of new stakeholders. The innovation models include the joint development with external partners, the use of formal networks or consortia, joint ventures, open innovation and open source. Depending on the level of influence of the partners, they will have more or less strength in relation to the project direction.

Other aspects that can be considered in the identification and engagement of stakeholders are the implementation of idea channels, use of experiments and prototypes, and control of deliveries. Additionally it is suggested to avoid believing that all ideas are within the company, letting the “owner” of the idea do project management from start to finish. This will impact the identification and management of stakeholders. It is important to the Project Manager define and select the strategy, coordinating the project management plans, specially Human Resources Management Plan and stakeholders channels.

References
AGILE MANIFEST. The Manifesto for Agile Development of software. Available at: http://agilemanifesto.org/iso/ptbr/manifesto.html . Accessed on: 07/2015.
CHIAVENATO, Adalbert. Introduction to General Theory of Administration: a comprehensive view of modern administration of organizations, 7 ed., Rio de Janeiro: Elsevier, 2003.
DOCHERTY, M. Primer on ‘‘Open Innovation’’: Principles and Practice. Visions, v. 30(2), p. 13-15, Abril 2006
JARUZELSKI, B; LOEHR, J.; HOLMAN, R. The Global Innovation 1000: Making Ideas Work. Strategy+business , 69. 2012.
JARUZELSKI, B.; DEHOFF, D.; RAKESH, B. Money Isn’t Everything: lavish R&D budgets don’t guarantee performance. Booz, Allen & Hamilton, Resilient Report. 2005.
JENSEN, M. B.; JOHNSON, B.; LORENZ, E. LUNDVALL, B. A. Forms of Knowledge and Modes of Innovation. Research Policy. v.36, 2007. p.680-693.
SAWHNEY, M.; WOLCOTT, R. C.; ARRONIZ, I. The 12 different ways for companies to innovate. Mit Sloan Management Review, v. 47, n. 3, 2006.
TEMAGUIDE. A guide to technology management and innovation for companies. European Communities: Fundación COTEC para la innovación tecnológica, 1998.
PMBOK- Project Management Institute. “Um Guia Do Conjunto De Conhecimentos em Gerenciamento De Projetos (Guia PMBOK): A Guide to the Project Management Body of Knowledge – Official Portuguese Translation”, 5th Edition, PMI, 2014.

4 Fallacies of Typical Project Management Thinking

Written by Ryan Downing on November 1, 2017. Posted in Articles. 3 Comments on 4 Fallacies of Typical Project Management Thinking

I have spent over a decade managing projects and studying different philosophies on what the best practices for this are.

During this time, I have managed many successful projects, several unsuccessful ones and obtained the Project Management Professional (PMP) and Certified Scrum Master (CSM) certifications.

As I continue to study the profession and see what works and what does not, I’ve found that many project managers are trying to force rules from a textbook into every project that they manage. They are using certain techniques that are generally acceptable for many projects but should not apply to the ones they are managing – hampering their ability to successfully bring the project to a conclusion.

While the methods they are trying to apply are proven to work with other projects, they cannot be viewed as the optimal methods for every project. Each project has its own nuisances and needs to be managed differently. These are several common philosophies that I see project managers trying to force on every project when a different approach would be better.

#1 – The Weekly Status Meeting

Few things in project management seem as sacred as the weekly status meeting with the customer. For the first part of my career, my managers insisted on it and I would reliably run these meetings without fail. However, when I was assigned to a new manager, he challenged my thinking and started asking me about the real effectiveness of those meetings. As I analyzed these status updates, I realized that the meetings I was running were not a very good use of everyone’s time.

For starters, meetings in general are increasingly under scrutiny by companies trying to get more out of their employees. Attentiv, a company dedicated to studying meetings to offer solutions to make them more effective, found that 63% of meetings take place without a pre-planned agenda and therefore, meeting participants feel that 33% of meeting time is unproductive.

In looking at the meetings I was running, I realized that mine were falling into this trap of not being planned out well or being effective. To correct this, I made it my goal to ensure that every meeting had an objective and agenda associated with it.

Interestingly enough though, as I tried coming up with an objective and agenda for the weekly status meetings, I found that for the most part, I could not come up with anything that would justify pulling multiple people away from their jobs. The content of the status meetings was typically updates on open items and project milestones.

By typing those statuses up to prepare the agenda, I realized that by sending that status update, I would have fulfilled the objective of the meeting. That is when I switched gears and stopped holding weekly status meetings but rather sent out status updates. This fulfilled the objective of keeping all the stakeholders aware of where the project was at without needing to take up more of their time on a meeting.

Initially, a few of my customers balked at the idea of not having a weekly status meeting. They too had it engrained in their thinking that the only way to manage a project was to meet weekly. But after several weeks of getting the email with project status updates, they agreed that it was a much better way to manage the project.

If you feel like you are spending too much time meeting with the stakeholders on projects you manage, I would encourage you to build a status report template that gives all the pertinent information in it (which you would have to gather anyway to prepare for a status meeting) and send that to the stakeholders in lieu of the status meeting.

#2 – Setting a Go Live Date

After spending over a decade working on software deployments, the first question I get from the customers when a new project is started is when they will be live on the software in a production environment. I understand the reasoning behind this as the company has just invested a lot of money into the software solution and want to know when they can start seeing some ROI.

Here is where the project manager will play a pivotal role in setting the correct expectations for the successful completion of the project. I have seen too often that project managers will provide new customers with a go live date at the very beginning of the project. If that date is not met, it will often lead to disappointment with the customer and have the potential to sour the vendor/customer relationship.

In order to avoid this, I tell the customer that I cannot give them an exact date that early on in the project. I let them know that there are too many variables that are yet unknown before committing to a project conclusion. Since the software I have implemented has always been very configurable for a variety of operational needs, I stress to the customer that my team of consultants need to first meet with them to understand unique business requirements before knowing when the project will realistically finish.

In the book Implementing Lean Software Development by Mary and Tom Poppendieck, they discuss deferring commitment, one of the seven principles of lean thinking. In the book they are quoted as saying “in the face of uncertainty especially when it is accompanied by complexity, the more successful approach is to tackle tough problems by experimenting with various solutions, leaving critical options open until a decision must be made”. I have applied this principle to complex software implementations where ending go live dates are being asked for prior to having all of the information needed to fully develop the solution.

During the business requirement gathering, I stress with my team to not only be looking for their operational needs to see how well they will fit into the core of the software, but also into the customer’s project team makeup. Having a customer with complex system needs that may have to be customized will certainly extend out a project timeline. However, even if their requirements are simple, if they do not have a competent project team with high level organizational backing, the project will probably also lag.

Advertisement
[widget id=”custom_html-68″]

That is why, only when the business definition sessions are finished and me and my team can fully analyze both the customer’s requirements and project team makeup, will I ever try to determine an end date for the project. I can remember one customer that as we went through the project definition process we uncovered many usability gaps and they had to spend more on customizations to the software than they did on the original software package. That project took much longer than a typical implementation.

Too many project managers commit to a deployment date very early on when they lack the full knowledge needed to make an informed decision. Most of the time, the dates that are chosen are ones with the best case scenario in mind – a customer with straightforward needs and a dedicated project team. By doing this, those project managers are setting the stage for problems in the future. If that customer’s project will be very complex or they do not have a team with a lot of dedicated time, it will require much more time than a standard implementation.

Rather than giving the customer unrealistic expectations before knowing all the variables that could impact the project outcome, project managers need to tell their customers that they will only be able to provide them with a project timeline with estimated go live date after the team has been able to analyze the customer business processes and team. Then when you are able to come up with a schedule, everyone involved will have a lot more confidence in being able to successfully go live in the agreed upon timeframe.

#3 – Providing a Very Detailed Schedule

A day does not go by as I’m reading the news that I do not come across a story of a project that is called out for being significantly overdue. Headlines like “the project was scheduled to be completed on January 15 and now it is months late” give readers the impression that the project team is not doing their job.

When I read stories like this, I can empathize with the project managers because I’ve been a part of my fair share of project like this in the past. I would set a very detailed schedule with exact dates like January 15 or October 3 and then when the project moved past those dates, there was a sense of failure for not finishing on time.

What I have learned in that setting of exact dates – especially ones that are far into the future – is risky for project managers to do. One thing that happens when an exact date is given is that it can be marked on calendars and if the project goes past that date, it is very obvious that a date was missed which paints the project manager and project team in a negative light.

The way I have been able to avoid doing this is to set more general timeframes and only commit to an actual date on the calendar when I have a high confidence that my team will be able to make that date. For example, I will say that an activity like this typically will take 2-3 weeks. That way, there is no actual date given that can be written down. Then even if the date extends past the deadline, there was never a firm commitment that it would be completed at a certain time. This gives the project manager the ability to still provide a customer with status updates but not over commit to actual deadlines.

I was on the other side of this once and the company that I was working with needed to get my team information. On multiple occasions, they gave specific dates like, “we will have this information to you by Friday”. When they did this, I put a calendar reminder in for the day they gave me. When the information was not provided, I asked the very same day and they gave a new exact date. Again, I put a reminder on the day and this date was also missed. After several iterations of this, my project team lost most of our confidence in that company to be able to deliver according to its promises.

The lesson I learned from this situation and others like it is that it is better to provide schedules as more general timelines based on historical norms than it is to give an exact date. For if an exact date is missed, it reflects much more poorly on the competency of the project team.

#4 – The Customer is Always Right

Ever since 1909 when Harry Gordon Selfridge, the founder of Selfridge’s department store in London, started using the phrase “the customer is always right”, it has become a popular motto of business to convince customers that they will receive excellent service. While it is important for services organizations to treat their customers with respect and try to delight them, I feel that it has become an excuse for project managers to allow the customers to dictate how their projects should be run.

Let me give you an example from a recent project that I was a part of. There was a customer who needed some additional assistance using the software they had purchased. They convinced my boss that the reason they needed help was because their initial training was not good enough and the software was not in tune with their business needs. My boss agreed and allowed the team to go to the customer’s site for a couple of days – for no charge.

After this had happened once, the customer had it in their mind that they were the ones running the show and asked several more times for onsite help at either no charge or a deeply discounted rate. Since the precedent had been set, it was difficult to tell them no and they took full advantage of the control they had to get what they wanted from my organization.

Looking back, I realize that in that situation, my team and I had surrendered control of the project in the name of pleasing the customer. Then once they realized they had the upper hand, they were the ones managing the project instead of myself.

A couple of years later, this same customer needed us to implement different software. By this time, we had a better process in place and were doing a better job managing the customers. Shortly after the project started, they tried again to assert themselves and get my company to give them free service time. However this time, instead of giving up control in the project, we pushed back on them and said they had signed off on each of the milestone exit criteria so additional time would come with a cost. They wound up backing off and my company did not lose money on this project like with the one earlier.

This experience taught me that successful project managers need to be able to provide exceptional customer service without relinquishing control of their projects. They need to not only manage the project plan and issue lists, but also the people.

The best way I have found to do this is to start with a very detailed project plan that outlines everything that has to be done along with timelines in which to get those tasks completed. The work that the customer needs to complete needs to be clearly expressed to them with an expected completion date. By doing this, the project manager is dictating what comes next and how long it needs to take to get done. They are the ones in control of the process.

If a customer tries working ahead because they feel they know better, the project manager can tell them that they have not completed the prerequisites to move to that task and the project team will not work with them until they have the prior tasks completed. Or if the customer does not get their work done on time, the project manager lets them know that the timeline and budget are getting extended out due to their inability to meet the project milestones. This ensures that the project manager and not the customer will be running the project.

I believe there are project coordinators and project managers. Most people in the profession are project coordinators – they can make sure items are being checked off the list – but they really are not in control of their projects. True project managers are individuals that can manage a list but more importantly, can manage people. They can put themselves in their customers’ shoes and serve them well without allowing them to dictate how the project will be run.

To conclude, project managers are essential to moving their objectives to a positive outcome. Each project is different and requires a unique approach to make it successful. I would encourage all project managers to not be so rigid in their thinking. They should learn different techniques and philosophies to build their own knowledge toolkit so that they can determine which principles should be used depending on the type of project they are managing. This ability to adapt will set them up to guide their projects to positive conclusion for all the stakeholders.

Abstract Summary

Many project managers are trying to force rules from a textbook into every project that they manage. They are using certain techniques that are generally acceptable for many projects but should not apply to the ones they are managing – hampering their ability to successfully bring the project to a conclusion.

This article reviews four common project management strategies and illustrates why those strategies should not always be used depending on the type of project that is being managed. The goal is to challenge project managers to look at each project differently and apply a unique approach to all of them.

5 Project Management Tips on How to Keep your Virtual Team on Track

Written by Amelia White on October 16, 2017. Posted in Articles. 6 Comments on 5 Project Management Tips on How to Keep your Virtual Team on Track

Flexible virtual teams and resources today are very popular among business owners. Now you can hire an expert and spend less on office management, rented other things you need to manage your company online.

Yet, there are other obstacles met while managing virtual teams. Among them is tracking project progress, following deadlines and prioritizing tasks to be done.

Development of software projects, digital marketing, customer care and many other work fields which are quite costly are now moved online. That is why tracking such works became a real headache for the project managers and business owners. However, you may optimize your work routine to keep your team on track and make sure that the work delivered at right time by the right people. Below you will find five project manager’s tips to ensure that your virtual team stays on the top of the work priorities.

1. STAY IN TOUCH WITH THE TEAM

First of all, you need to understand that you won’t be able to stay on track with your team if you don’t keep in touch with them. Do you know the saying “out of sight, out of mind?” It means that if nothing reminds you about task, notion or event you soon forget about it.

You need to create an environment and opportunities to be in touch with your team. Of course, you have checkpoint meetings, regular calls and established communication within message system or call software. But you need to think of going beyond.

It sounds simple and probably you are doing that while working with the small team, but if you have a large and much-dispersed team when team members live in different time zones. Of course, it will be difficult to stay in touch with each team member during working day. The key to success here is planning. Plan your calls during the day, it will be okay if you’ll start working later, you may use Google Calendar for example to plan your calls and keep on track all the tasks and communication you have.

So what is a benefit of tracking each team member with personal communication? Well, it is an ability to resolve all possible issues before they became a bigger issue for the project. You will find out what is blocking each team member from the progress and will be able to define the next step earlier. This will help you to keep all the tasks on track and make your team more effective.

Yet, you should remember that the call shouldn’t be long and you need to prepare for it before the call itself.

2. USE DIFFERENT ONLINE TOOLS

Technology is the way to bring your team closer and make the work and collaboration effective. There are numerous tools you can use during work on your projects. Today, there are different technology options available to you.

IT and marketing virtual teams use Slack for a chat, documents sharing and other project related features which require timely updates. Online mind mapping tools, like iMindQ allow virtual team members create project plans and flow diagrams together with screen sharing features.

Advertisement
[widget id=”custom_html-68″]

Flexible project management systems like Wrike, Jira or Trello make it possible for project managers to set and track projects with their virtual teams. These tools save a lot of time and allow adapt to changing requirements of any even the most complex project.

There are numerous other tools available on the market, which are aimed to make any kind of project completed by the virtual team successful and fully delivered.

3. ASK THEIR MANAGER TO HELP (IF THE PERSON ATTACHED TO YOUR TEAM WORKS ON THE BEHALF OF OTHER COMPANY)

Sometimes it is very difficult to get information or the task completed on time. Both parties are interested in the results and profit. However, we are all people and have our own character. If you are not getting in time feedback and report, worried about the deadline, and the person assigned to your project seems to ignore your tasks, it is time to talk with their manager. Of course, it will be possible only if this person works on the behalf of other company.

Try to carefully contact their manager and ask what is happening with your team member. Maybe the person you are referring to is on sick leave or have some personal issues, yet, you need to be sure that the project will be delivered on time.

If you are working with freelancers, and person disappeared, you need to find another contractor.

4. VARY YOUR COMMUNICATION STRATEGIES

It is good to have a conference call once a week to discuss the project with your team members, or daily scrams via Skype. But sometimes to stir up your team members once a month use something different. For example:

Audio meeting if you use video or vice versa
Dividing team members into smaller groups and meeting with them separately
Skipping the actual meeting and sending out email updates
Asking one of team members to report on others tasks to see if he or she also tracks progress
Meeting in person to talk not only about the project progress but also to get feedback in your management and relationships with others.

If you mix formats the interaction within the virtual team can become more effective since such changes can push team member for whom it is hard to express during standard meeting used by your team.

5. ASK TEAM MEMBERS TO DEFINE THEIR OWN DELIVERABLES

When you set time-frames yourself you more likely will follow them. This also applies to others, since the person will feel a sense of responsibility. Ask each team members to give you their own time frames on the tasks assigned to them. Moreover, don’t forget to delegate some of your tasks and encourage other team members to do so. Even a good worker is better in something than others. Such flexibility may reduce pressure and make your team more effective.

I hope these five tips will help you to keep your virtual team on track and encourage their creativity. They will also help you to establish better relationship and trust inside the team. If you have other ideas how to make virtual teams more effective please let us know.

Process and Project management joining forces

Written by Yasar Ajlouni on October 10, 2017. Posted in Articles. 4 Comments on Process and Project management joining forces

One can debate if project management was practiced before process management or vice versa, building the Pyramids was a historical project, unique and definitely with a start and an end.

Additionally and in ancient times; the Egyptian economy was a barter system where people paid the Government interest, crops and precious stones, and in return the Government kept the peace, and saved the food. This is perhaps one of the oldest processes from ancient history.

Regardless if process or project management came first, now a days, both contribute strategically to the success of any modern organization. As a matter of fact, project management is a process itself; PMI for example defines (Initiation, planning, execution, monitoring & Controlling, and closing) as process groups.

Stated differently, projects better succeed when the current processes are rightly managed. Moreover project deliverables are usually products, services or results, the latter can sometimes be in the form of new processes, as an example if we pilot an introductory Lean six sigma project , to introduce and test the practice ; we can after delivering satisfactory results , standardize the piloted process in conducting supplementary Lean six sigma projects .

Having shed some light of some of the possible interaction between processes and projects, one is now more aware of how interrelated both management disciplines are. The key difference between both practices is that any project is done once, while processes are executed on a continuous basis, other differences relate to optimization, processes are optimized for efficiency and consistency, while projects are optimized once the project is completed.

The real impact of process management and project management is challenged as the work gets done across departments. As organizations grow bigger in size, a process can cut across several departments horizontally, for example the supply chain process in an industrial organization links the sales process with the manufacturing process. Implementing an ERP System across an enterprise is an example of a cross functional project, looking at ERP implementation provides some illustration of process and project management joining forces. After selecting the vendor, the consultants start capturing the as is processes, the “to be” processes are “best practice processes” that giant ERP providers excelled in designing. Implementation is mainly migration to the new processes. An organization intending to implement an ERP solution is at greater advantage, if it already had its processes modeled by the BPM team, thus saving implementation time and costs. Additionally the BPM teams would take the process oriented approach, enhancing the ERP implementation success rate. Concurrently the presence of a project management capability in such organization intending to implement an ERP solution can strongly enhance the project success. It is not rare to find organizations with PMOs and BPM centers of excellence joining forces for automation and Artificial Intelligence projects. What are rare to find is organizations that have project and process management specialists working in one department.

Advertisement
[widget id=”custom_html-68″]

The ERP implementation example, can also be looked into to demonstrate how project and process management teams can work together in functional organizations; It is worth mentioning that the introduction of ERP systems in the 1990’s obligated organizations to consider their positioning to process, as the ERP solutions offered an alternative to the functional processes used commonly at that time. Since ERP modules are predesigned, organizations started focusing horizontally, this led to creating new process roles like process owners and process stewards, and in some cases process designers, architects, analysts and process mangers.

In essence combined process and project management practices are ideal management philosophies to overcome functional barriers , end to end process management is sometimes managed though contracts between the supplier process and the customer process , this concept creates an additional internal customer, whereby the supplier process must meet its obligations to the customer process . Other organizations use SLA’s between business units or divisions and align the SLA interaction with the concerned process. This alignment keeps expectations and maintains governance. Project management on the other hand created the matrix organization for project coordination, what the matrix organization provided over the functional one; was literally the right balance between authority and responsibility. Projectized organizations completely work in project teams.

Capability Maturity Model Integration CMMI is a process improvement approach consisting of a collection of best practices where its value has been established over time. CMMI for Development contains practices that cover process management, project management, engineering, and other supporting processes used in development. If we explore the constituent process areas under project and process management categories, we shall come across process areas like integrated project management and Organizational process performance, these process areas themselves are in a sense integration processes, joining the forces of these integrated processes adds value as a cumulative integrative force, Noticeably it is then not rare to find process and project management functioning together in a process improvement model.

Whatever benefits are realized through joining the forces of process and project management, the final judge is the customer. In their premise to achieve successful customer outcomes, organizations can build and design their businesses outside in, starting from the customer perspective , in doing so they opt to join forces of process and project management to design and execute processes that produce products or services that meets and exceeds customer’ s needs and wants .