 | |
| WHAT IS A STRATEGIC PROJECT? |
Organizations can be good at tactical projects, such as moving to a new building or introducing a new product. These are projects that have one operational goal, which probably does not entail contributions by most employees within the organization. In these projects, meeting a tactical goal on time and within budget are key considerations. A strategic project, on the other hand, has a primary goal of gaining the competitive advantage by focusing on the organization’s overall direction.
Analysis
Strategic projects are designed to meet one or more strategic goals. These can include purchasing new companies to meet sales targets well into the future. The goal of these projects is to provide the road map to the question: “Where do we want to be five years down the road?” These types of projects may come from a SWOT, or Strengths-Weaknesses-Opportunities-Threats, type of analysis where an organization has to determine where it is currently in comparison with where it thinks it ought to be.
Download Also:
Breadth
A strategic project, entailing the bulk of the workforce, may dictate a need for retraining, and processes may have to be redesigned to keep the standards of operations at a high level. Examples include major overhauls of systems, consolidations of operating companies or the purchase or spin-off of business units.
Steps
Strategic projects should have both a breadth span and address specific strategic goals to be defined as such in comparison with a tactical project. From a practical perspective, for a strategic project to be successful, it must have the support of the executive management team, who will not only provide support but also articulate the vision to those involved in the project. Change is often hard for employees, and it’s important to build excitement and support for the project by compellingly expressing the vision of how good things will be for all involved.
Tactics
Tactical goals co-exist within the strategic project and should be completed on time and within budget. For example, to purchase a new company, legal documents must be prepared, vendors and customers must be notified, and business processes must be created. These tactical goals are created when teams determine ways to achieve the strategic goal. A brief History of Project Management In this brief history of project management I chart all the major developments and events in the discipline as far back as there are records. Although there has been some form of project management since early civilization, project management in the modern sense began in the 1950s. The Project Management Time line
2570 BC: The Great Pyramid of Giza Completed
The Pharaohs built the pyramids and today archaeologists still argue about how they achieved this feat. Ancient records show there were managers for each of the four faces of the Great Pyramid, responsible for overseeing their completion. We do know there was some degree of planning, execution and control involved in managing this project. 208 BC: Construction of the Great Wall of China Later still, another of the Seven Wonders of the World was built. Since the Qin Dynasty (221BC-206BC), construction of the Great Wall had been a large project.
According to historical data, the labour force was organised into three groups: soldiers, common people and criminals. The Emperor Qin Shihuang ordered millions of people to finish this project. 1917: The Gantt chart Developed by Henry Gantt (1861-1919) One of the forefathers of project management, Henry Gantt is best-known for creating his self-named scheduling diagram, the Gantt chart. It was a radical idea and an innovation of worldwide importance in the 1920s. One of its first uses was on the Hoover Dam project started in 1931. Gantt charts are still in use today and form an important part of the project managers’ toolkit.
1956: The American Association of Cost Engineers (now AACE International) Formed
Early practitioners of project management and the associated specialities of planning and scheduling, cost estimating, cost and schedule control formed the AACE in 1956. It has remained the leading professional society for cost estimators, cost engineers, schedulers, project managers and project control specialists since. AACE continued its pioneering work in 2006 releasing the first integrated process for portfolio, programme and project management with their Total Cost Management Framework.
1957: The Critical Path Method (CPM) Invented by the Dupont Corporation
Developed by Dupont, CPM is a technique used to predict project duration by analysing which sequence of activities has the least amount of scheduling flexibility. Dupont designed it to address the complex process of shutting down chemical plants for maintenance and then with maintenance completed restarting them. The technique was so successful it saved the corporation $1 million in the first year of its implementation.
1958: The Program Evaluation Review Technique (PERT) Invented for the U.S. Navy’s Polaris Project
The United States Department of Defense’s US Navy Special Projects Office developed PERT as part of the Polaris mobile submarine launched ballistic missile project during the cold war. PERT is a method for analysing the tasks involved in completing a project, especially the time needed to complete each task and identifying the minimum time needed to complete the total project.
1962: United States Department of Defense Mandate the Work Breakdown Structure (WBS) Approach
The United States Department of Defense (DOD) created the WBS concept as part of the Polaris mobile submarine launched ballistic missile project. After completing the project, the DOD published the work breakdown structure it used and mandated that this procedure be followed in future projects of this scope and size. WBS is an exhaustive, hierarchical tree structure of deliverables and tasks that need to be performed to complete a project. Later adopted by the private sector, the WBS remains one of the most common and effective project management tools.
1965: The International Project Management Association (IPMA) Founded
IPMA was the world’s first project management association, started in Vienna by a group as a forum for project managers to network and share information. Registered in Switzerland, the association is a federation of about 50 national and internationally oriented project management associations. Its vision is to promote project management and to lead development of the profession. Since its birth in 1965, IPMA has grown and spread worldwide with over 40,000 members in more than 40 countries.
1969: Project Management Institute (PMI) Launched to Promote the Project Management Profession
Five volunteers founded PMI as a non-profit professional organisation dedicated to advance the practice, science and profession of project management. The Commonwealth of Pennsylvania USA issued Articles of Incorporation for PMI in 1969 which signified its official start. During that same year, PMI held its first symposium in Atlanta, Georgia and had an attendance of 83 people. Since then, the PMI has become best known as the publisher of “A Guide to the Project Management Body of Knowledge (PMBOK),” considered one of the most essential tools in the project management profession today. The PMI offers two levels of project management certification, Certified Associate in Project Management (CAPM) and Project Management Professional (PMP).
1975: PROMPTII Method Created by Simpact Systems Limited
PROMPTII was developed in response to an outcry that computer projects were overrunning on time estimated for completion and original budgets as set out in feasibility studies. It was not unusual to experience factors of double, treble or even ten-times the original estimates. PROMPTII was an attempt to set down guidelines for the stage flow of a computer project. In 1979 the UK Government’s Central Computing and Telecommunications Agency (CCTA) adopted the method for all information systems projects.
1975: The Mythical Man-Month: Essays on Software Engineering by Fred Brooks
In his book on software engineering and project management, Fred Brooks’s central theme is that “Adding manpower to a late software project makes it later.” This idea is known as Brooks’s law. The extra human communications needed to add another member to a programming team is more than anyone ever expects. It naturally depends on the experience and sophistication of the programmers involved and the quality of available documentation. Nevertheless, no matter how much experience they have, the extra time discussing the assignment, commitments and technical details as well as evaluating the results becomes exponential as more people are added. These observations are from Brooks’s experiences while managing development of OS/360 at IBM.
1984: Theory of Constraints (TOC) Introduced by Dr. Eliyahu M. Goldratt in his Novel “The Goal”
TOC is an overall management philosophy that is geared to help organisations continually achieve their goal. The title comes from the view that any manageable system is limited in achieving more of its goal by a small number of constraints, and there is always at least one constraint. The TOC process seeks to identify the constraint and restructure the rest of the organisation around it by using Five Focusing Steps.
The methods and algorithms from TOC went on to form the basis of Critical Chain Project Management. 1986 Scrum Named as a Project Management Style Scrum is an agile software development model based on multiple small teams working in an intensive and interdependent manner. In their paper “The New New Product Development Game” (Harvard Business Review, 1986), Takeuchi and Nonaka named Scrum as a project management style. Later they elaborated on it in “The Knowledge Creating Company” (Oxford University Press, 1995). Although Scrum was intended for management of software development projects, it can be used to run software maintenance teams, or as a general project and programme management approach.
1987: A Guide to the Project Management Body of Knowledge (PMBOK Guide) Published by PM
First published by the PMI as a white paper in 1987, the PMBOK Guide was an attempt to document and standardise accepted project management information and practices. The first edition was published in 1996, followed by a second in 2000, and third in 2004. The guide is one of the most essential tools in the project management profession today and has become the global standard for the industry.
1989: Earned Value Management (EVM) Leadership Elevated to Under-secretary of Defense for Acquisition Although the earned value concept has been around on factory floors since the early 1900s, it only came to prominence as a project management technique in the late 1980s early 1990s. In 1989, EVM leadership was elevated to the Under-secretary of Defense for Acquisition, thus making EVM an essential part of programme management and procurement. In 1991, Secretary of Defense Dick Cheney cancelled the Navy A-12 Avenger II Programme because of performance problems detected by EVM.
The PMBOK Guide of 1987 has an outline of Earned Value Management (EVM) subsequently expanded on in later editions. 1989: PRINCE Method Developed From PROMPTII Published by the UK Government agency CCTA, PRojects IN Controlled Environments (PRINCE) became the UK standard for all government information systems projects. A feature in the original method, not seen in other methods, was the idea of “assuring progress” from three separate but linked perspectives. However, the PRINCE method developed a reputation as being too unwieldy, too rigid and applicable only to large projects, leading to a revision in 1996.
1994: CHAOS Report First Published
The Standish Group collects information on project failures in the IT industry with the objective of making the industry more successful, showing ways to improve its success rates and increase the value of IT investments. The CHAOS report is a biennial publication. 1996: PRINCE2 Published by CCTA An upgrade to PRINCE was considered to be in order and the development was contracted out, but assured by a virtual committee spread among 150 European organisations. Originally developed for IS and IT projects to reduce cost and time overruns; the second revision was made more generic an applicable to any project type.
1997: Critical Chain Project Management (CCPM) Invented Developed by Eliyahu M. Goldratt, Critical Chain Project Management is based on methods and algorithms drawn from his Theory of Constraints (TOC) introduced in his 1984 novel titled “The Goal.” A Critical Chain project network will keep the resources levelly loaded, but will need them to be flexible in their start times and to switch quickly between tasks and task chains to keep the whole project on schedule.
1998: PMBOK Becomes a Standard
The American National Standards Institute (ANSI) recognises PMBOK as a standard in 1998, and later that year by the Institute of Electrical and Electronics Engineers (IEEE) 2006: “Total Cost Management Framework” Release by AACE International Total cost management is the name given by AACE International to a process for applying the skills and knowledge of cost engineering. It is also the first integrated process or method for portfolio, programme and project management. AACE first introduced the idea in the 1990s and published the full presentation of the process in the “Total Cost Management Framework.
” 2008: 4th Edition of PMBOK Guide Released
The fourth edition of the guide continues the PMI tradition of excellence in project management with a standard that is easier to understand and implement, with improved consistency and greater clarification. The updated version has two new processes not in the previous versions. 2009: Major PRINCE2 Revision by Office of Government Commerce (OGC) A major revision has seen the method made simpler and more easily customisable, a common request from users.
The updated version has seven basic principles (not in the previous version) that contribute to project success. Overall the updated method aims to give project managers a better set of tools to deliver projects on time, within budget and to the right quality. What’s Next? With globalisation come ever bigger challenges and the need for increased speed-to-market with products and services. Projects become larger, more complex and increasingly difficult to manage. Teams are more diverse and spread across the world. The economic crisis pushes work offshore to low cost countries, which itself presents several issues.
The world is changing and project management will need to change with it. No doubt new techniques and better practices will arise as we push the boundaries of what is possible and new challenges arise. Human need drives us forward to a better future and with it will come improvements in the way we manage projects. When and where these developments will happen is uncertain, but they will happen.
Avoid Social Engineering's Threat at your PMO.
Social engineering is more commonly associated with cyber security attacks, but it can also be used to manipulate your project team. And in some ways, PMOs may be more vulnerable to this kind of exploitation, largely because of the need to be in near-constant contact with end users, stakeholders, business partners, and other supporters. While you may have already talked with your team about managing confidential information , it’s important to remember that a number of less-obvious opportunities exist for external folks to pry sensitive information out of your team members. Below are a just a few examples of how social engineering can put your PMO in jeopardy.
You bump into a former coworker at a networking event and enjoy some garden-variety gossip about how things are going, including an upcoming project you’re excited about that’s sure to position your company for more sales next year. Uh oh, looks like you should have asked your friend about their new position first—they just told you they now work for a competitor that’s desperate to gain market share in your industry. A vendor might be willing to give you a break on some new equipment if you can tell them where they need to be on price to make the sale.
Think carefully before you divulge your budget numbers—you’re in danger of losing your ability to negotiate, plus you may find the “discount” price exactly matches the funds you have available. Potential collaborators will naturally have a lot of questions for you, but hold off on revealing anything sensitive until non-disclosure agreements are signed. Even the most honourable associates could leave the bargaining table with highly damaging information if negotiations fall through—you don’t want to think about what could happen if the meeting was a ruse perpetrated by someone shady
No more project managers?
Time to celebrate! Why do we still have project managers? Hasn’t their time been and gone? That’s not to say that project management isn’t important, but do we really need a specific role for it anymore?
Projects are Business As Usual
For many organisations, continual projects are the new normal. Often the same team will carry on from one project to another. While the end product and the client may change, the team works together for months or years at a time. And that means the team’s manager is very far away from the common idea of a matrix-managing, temporary project management expert brought in to deliver the project that many think of as a project manager.
Project management becomes just one part of a manager’s role In these situations, there’s little difference between a project team’s “project manager” and the manager of any other team in a business. While how they manage the workflow may be different, does it really make the role so different that we need a specific name for it? Instead, isn’t it the case that the project management parts of their job are just one of the many hats they need to wear as a manager?
Project management is just a set of techniques, not a role
So do we really need so many “project managers”? Is there really enough difference between project management and general management to require a separate professional career path?
Project Management and Communications
Some people think that being a project manager is all about sticking your nose in a set of project plans and setting milestones and such like. This is certainly an essential part of the role but it is far from being the only one. Another area of the job you will want to spend a lot of time on in is the communication. This is an important aspect of the project management role for the following reasons.
A Lot of Stakeholders and Team Members
Even the most modest project will tend to have a number of people who need to know about its progress and about any issues which crop up during it. Modern projects also often have the added complication of having remote team workers and stakeholders scattered all over the globe. Without a solid communication strategy it simply isn’t possible to keep everyone up to date and informed. Don’t forget that the stakeholders need to sign the whole thing off when it is finished, so there is no point in alienating them before then.
A Changeable Situation
Projects are by their very nature fluid and ever changing pieces of work. If they weren’t then you could simply say what you are going to do and then advise everyone once it is finished. Instead of this you need to consider the fact that the there will be changes and challenges all the way until the end. By keeping the team and the stakeholders fully up to date there will be no nasty surprises waiting for them to discover later on.
A Lot of Planning
At the start of the project there will be a project plan drawn up and you as the project manager will do your very best to stick to it. However, it will be filled with a lot of interdependencies and you won’t be able to control all of them. This means that everyone who has a hand in the process needs to know whether the project is on target or not. For example, if you are designing a new process you will probably need to arrange for some staff training to be given and a new staff manual to be written. There are sure to be a number of different people involved in that work and you need to co-ordinate everything so that each job is carried out at the right time. This would be pretty much impossible if you tried to work in isolation without either inward or outward communication.
A High Degree of Transparency
There are many business people who don’t really like to see project work getting carried out on their area. In a lot of cases and to some degree I think this is because they are comfortable with their current situations and don’t want to see any changes upsetting the apple cart and complicating their lives. However, there are also those people who are openly hostile to the idea of a project because they fear that they will get lumbered with something which they don’t want or need. Hopefully you won’t come across any of these people in your projects, but if you do then the best approach is to simply carry out all of the work in the most transparent way possible. Even if the stakeholders are open and helpful you will want to make sure that you are completely transparent in what you do for them.
Early Warnings
Things can go wrong in any project and project managers can make mistakes or wrong assumptions. If you are working with a limited amount of communication then it could be too late before you notice this. On the other hand, if you keep the lines of communication open then you stand a much better chance of finding and resolving problems before it is too late. You certainly don’t want to fall into the trap of believing that you know everything or that you don’t want people picking holes in your work.
Projects are pieces of work which can benefit immensely from having as many pairs of eyes as possible focusing on them. Anyone who points out a new risk, a false assumption or a mistake is helping you resolve an issue before it becomes too late to effectively deal with it. This means that it is really in your interests to get information out to them and find out whether there any faults in your thinking or not.
Organizational cultural and structural influence project management more than you realize
The differences in project management success rates may be a result of the fact that some organizations do a better job of training their project managers. So they may be more skilled and knowledgeable in the project management discipline. But the way your organization deals with training is just one aspect of your overall organizational culture. A number of big-picture factors influence your ability to deliver projects successfully. Let’s look at two of them: culture and structure.
Culture has a huge effect on your success rate
Your organization’s culture has a lot to do with the success rate of your projects. Keep in mind that I’m talking about projects all throughout your organization, not just about one particular project. The term culture generally means “how we do things around here.” Imagine that someone asks you how successfully your organization delivers projects. If you say, “We’re pretty poor at delivering projects,” you’re voicing a perception of one aspect of your culture. Culture comes into play on projects in a number of areas.
Process orientation
Many organizations have good processes in place and people generally follow them. This is perhaps the biggest single factor in overall project success. If your organization follows a good, scalable project management process, you’re more likely to be consistently successful on your projects. The entire project team generally knows how to create and follow a work plan, and can use standard processes to effectively handle risk, scope change, and issues.
Governance
Many organizations have processes in place, but no one follows them. This highlights a problem with management governance. In simplistic terms, governance is the management function that has to do with making sure people do what they’re supposed to do. Typically, if your management structure is engaged and interested in projects, and if managers make sure that your project management process is followed, you’ll be more successful. If every project manager is on his or her own and management support is haphazard, however, you’ll tend to fail.
Training
Some organizations do a poor job of training project managers. Typically, these organizations do a poor job of training in general. If project managers generally don’t have the right skills (other than from the school of hard knocks), you won’t be successful.
Roles and responsibilities
In successful organizations, people typically know the role they play on projects and what is expected of them. This includes active sponsors, interested clients, and engaged management stakeholders. The sponsor, for instance, needs to perform a quality assurance role and be the project champion in his or her organization. If your organization starts projects and leaves the
project manager in a leadership vacuum, you’re not going to be consistently successful.
Culture plays perhaps the biggest role in whether your organization is successful in executing projects. If your organization has difficulty completing projects successfully, you can’t blame the project managers. They’re only toiling within a culture that’s not supportive of their efforts. Managers, including the head of the organization, need to step up and evaluate the project culture. Until the culture changes, project managers will consistently struggle to be successful.
Your organizational structure can help or hurt project success
To a lesser degree, your organizational structure can get in the way of, or help support, the overall success of your projects. I say that this is a lesser problem because, to a certain extent, you can change your organizational structure. In fact, you can change the organization chart frequently, and some companies do just that. Culture, on the other hand, is not easily changed. It can take years for a large organization to develop a culture of excellence (although it doesn’t take nearly as long to fall back into mediocrity).
Some organizational structures can definitely impair your ability to deliver projects. First are those organizations whose project teams are doing support work. If your project organization does support as well, it usually means that support issues will pop up and take the focus away from the project. A lot of multitasking and thrashing takes place as you move from support work to project work to support work. It’s usually very difficult to prepare good estimates and meet your scheduling commitments. You may be forced into this structure if your staff is small. In the last company I worked at, for instance, we had 15 people who worked on support, projects, and enhancements.
However, we didn’t have enough people to specialize in either support or project work. This made it difficult to meet all of our project commitments. Instead, we had to do a good job of managing expectations. Your organizational structure may also impede the ability to share resources. For instance, if your project team needs a resource with a specific expertise, you may not be able to easily share that person with another functional area. Some of this is also related to your culture.
Ask yourself whether a different organizational structure would help. If it would, you may have an organization problem. If it wouldn’t help, your culture is probably not supportive of resource sharing. When I worked for a beverage company, for instance, we went through a period of two years when the management team developed a strong culture of resource sharing between projects. However, with the arrival of a new CIO and new director, resource sharing was discouraged (and punished). So, the culture quickly reverted to resource hoarding.
Step back and see the big picture
A number of organizational factors support or inhibit the ability of your project managers to be successful. Granted, culture is a broad term, but your organizational culture plays the biggest role in whether you’re able to deliver projects successfully. You can’t attack a culture of mediocrity (or a culture of failure) one project at a time. You need to address it in a broad and multifaceted way. Your organizational structure can also help or hinder your success rate. The structure can determine how well you focus on projects and how easy it is to share resources between organizations.
Managing Confrontation in Multicultural Teams Everyone knows that a little confrontation from time to time is constructive, right? And the classic business literature confirms it. for example, discusses at length how to achieve the right amount of confrontation for ultimate team effectiveness — and concludes that fear of conflict is one of the five major barriers to success. But what if you come from a culture where confrontation is downright rude? Or what if you just happen to have people from such cultures on your team? The fact is that all-American teams — or mono-cultural teams of any nationality — are becoming a thing of the past (except in the classic business literature).
In the oriental cultural context, confrontation is considered rude, aggressive, and disrespectful. Open disagreement, particularly in a group forum, is strongly avoided. Even asking another’s point of view can feel confrontational in our culture. We had a meeting with a group of Canadian managers from headquarters, where they went around the table asking each of us: “What do you think about this? What do you think about this? What do you think about this?” At first we were just shocked that we would be put on the spot in a meeting with a lot of people. That is just an insult! And here’s what a Canadian executive said (making the American way described by Lencioni sound really quite moderate): Confrontation is part of Canadian culture.
The Canadian school system teaches us to first build up our thesis (one side of the argument) and then to build up our anti-thesis (the opposite side of the argument) before coming to a synthesis (conclusion). And this is exactly how we intuitively conduct meetings. On Canadian teams conflict and dissonance are seen as revealing hidden contradiction and stimulating new thinking. We make our points passionately. We like to disagree openly. We like to say things that shock. And afterwards we feel that was a great meeting and say, “See you next time!” With confrontation you reach excellence, you have more creativity, and you eliminate risk.
Now imagine that you have to lead a team with both Canadian and eastern members. How on earth do you cope? And what happens if there are a whole heap of other nationalities thrown into the mix, all with differing cultural attitudes to confrontation? Well, it is possible to manage a global team and to reap the benefits of disagreement. But you have to tread carefully, using tactics like the following and respecting the various cultures on the team.
- Do your preparation. In many Asian cultures the default purpose of a meeting is to put a formal stamp on a decision that has been made before the meeting in informal pre-meetings. In Japanese this is called Nemawashi. The tendency rings true to various degrees in China, Malaysia, Korea, and Thailand. If you lead a team with members from one of these countries, try making one-on-one phone calls before the formal meeting to hear the real deal.
- Depersonalize the confrontation.Instead of asking people to express their opinions and challenge one another’s ideas in a meeting, ask team members to send all their ideas to a nominated third party before the meeting and have that person create a list of ideas without stating who had the suggestions. This way, participants can confront each idea during the meeting — without confronting the person associated with it.
- Change your language.You might try following the advice of Sean Gilbride, an American living and managing in Mexico. He says: “I soon learned that if I wanted to encourage team debate it was important to use phrases like ‘I do not quite understand your point’ and ‘please explain more why you think that’, and to refrain from saying ‘I disagree with that’ which would shut down the conversation completely.”
Related Topics:
The Author: Ala'a Elbeheri
About:
A versatile and highly accomplished senior certified IT risk management Advisor and Senior IT Lead Auditor with over 20 years of progressive experience in all domains of ICT.
• Program and portfolio management, complex project management, and service delivery, and client relationship management.
• Capable of providing invaluable information while making key strategic decisions and spearheading customer-centric projects in IT/ICT in diverse sectors.
• Displays strong business and commercial acumen and delivers cost-effective solutions contributing to financial and operational business growth in international working environments.
• Fluent in oral and written English, German, and Arabic with an Professional knowledge of French.
• Energetic and dynamic relishes challenges and demonstrates in-depth analytical and strategic ability to facilitate operational and procedural planning.
• Fully conversant with industry standards, with a consistent track record in delivering cost-effective strategic solutions.
• Strong people skills, with proven ability to build successful, cohesive teams and interact well with individuals across all levels of the business. Committed to promoting the ongoing development of IT skills throughout an organization
Post a Comment