Промышленный лизинг Промышленный лизинг  Методички 

1 2 3 4 5 6 7 8 9 10 [ 11 ] 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101

Avoid mistakes.

Reduce cost.

Reduce risk.

Meet project schedules.

Identify and correct errors early.

Avoid excessive documentation.

Many project managers are faced with developing products within a specific time with limited resources. Adopting an incorrect methodology or having no project framework in place can very easily cause you to have schedule and cost slippages, as well as miscommunication within the team. Some methodologies consume many hours, and you must follow project templates and processes, making the daily execution of the project difficult. Selecting the correct methodology allows you to develop a saleable fit to sell product within the correct time frame, forcing you to focus on the most appropriate documentation and processes, without wasting time on administrative tasks that have no purpose. You do not have to use the most detailed processes. But how do you know which methodology is right for you? Its like trying on a pair of shoes you have to select the right size, color, make, and style. We examine this question in detail in Chapter 3.

Understanding Methodology Trends

Some of the most common questions that arise on the topic of project methodologies are:

Do we honestly say that we understand the working of a basic project management methodology? Do we understand why the various project management methodologies differ? Why does the life cycle vary between project types?



What does this tell us about the generic practice of project management?

If technology managers repeatedly tell us they need more time to plan the implementation and that they should have used fewer tools, hired more outside consultants, and allowed more time for training users and retraining staff, what does it tell us about our project? It tells us that the project planning was inadequate and that, most likely, the project methodology was not followed correctly.

Instead of following a standard methodology for conducting projects, many companies have been relying on technical wizardry to get projects done. In fact, communication is often so bad that it outweighs their tool-centric approach to managing the project. This leads to project management burnout. Project management is not about deadlines; it is about tracking, controlling, and improving the process of change. Lack of time may be the excuse, but why isnt the initiative planned more carefully? Perhaps it is that organizations compelled to reengineer their business processes dont have the luxury of time due to the amount of projects being undertaken by organizations as well as the speed-to-market factor. Are competitive pressures so intense that project management succumbs in the triage of crisis management?

The methodology process itself is sometimes part of the problem because when you start fiddling with the building blocks of your business, projects take on a life of their own. Therefore, an assessment of the business components must be brought into a more realistic relationship with the methodology that is going to be used. The relationship among these variables is often not linear, and this needs to be noted.

Perhaps we all have unrealistic expectations of the power of technology and the human dynamics of change. No matter how rapidly business requirements shift and technologies improve, some steps in project management cannot be combined. To keep a project methodology in sync with reality, learn from those who have gone before you. Brian Hurley, founder of Musk industries succinctly defined the situation: Deliver your projects as you would a newborn. Conceive decisively. Gestate, prepare and then again. Dont bash your ship on the siren of complacency. Procrastination will lure you past your due date, and no late-stage boom in the headcount of gestating mothers will hasten the outcome (p. 15).

Strategic Focus

Strategy always comes before any tactics. Its similar to thinking before doing. The strategy must be correct before we select a project or development methodology. In other words, you must be doing the right thing and only then can the necessary tactics support that newfound strategy. (Its like executing a certain methodology only after we know what our objectives are.) Strategy as it has always been and will always remain is the perpetual struggle for advantage. The objective of strategy is to take actions that build, sustain, and compound advantage. Acquiring and retaining customers are functions of your advantages. Parrying competitors is a function of your advantages. Competitive organizations that parry with their competitors do so in order to understand their competition, allowing them to understand, maintain or build leaner, quicker processes, eventually coming in earlier to market with better products.

History proves that the best strategy and tactics are achieved in areas fundamental to the core strengths of the company (i.e., having a project management discipline). With the right strategy, the battle is only half won; the strategy succeeds only with professional execution of tactics. Many problems arise when planning is separated from that execution. The important thing is to get started. Too much time spent on planning is also not good. You get caught up doing so much planning and strategizing that you never move forward you end up wasting time on planning and that breeds indecisiveness and error.



It is often better to engage in some form of simultaneous planning and implementation (e.g., this is where concepts such as RAD, OO&D, and concurrent engineering make huge impacts on project executions). A common mistake is to consider planning as only a mental process, an idea in our heads that looks at the past and adjusts to the future. If your plan is not in writing, you really dont have a plan at all. A simple written plan works best.

The purpose of strategy is to provide rapid direction and concentration of effort as organizations continually strive to improve their position or gain the upper hand in the marketplace. Speed is the ultimate factor here. Throughout history, winning generals developed ways and means of moving faster than their opponents. Napoleons troops marched at 120 paces per minute while his opponents marched at only 70 paces. Because Napoleons troops marched almost twice as fast as his opponents troops, speed gave him a tremendous advantage, which was a major contributor to his success. Using this analogy, project managers also need to use a methodology that is not only faster than the competition, but also that is disciplined enough to ensure that the products or systems are developed, tested, and implemented properly. Figure 1.6 depicts two scenarios. The left side shows an organization faced with an unprofitable situation the strategy is not correctly aligned to its portfolio of projects. On the right-hand side of the illustration, we see an organization that has undergone an assessment; as a result, its objectives are aligned to its project portfolio.

Projects of varied size and complexity require different project management skills and techniques to effectively and economically manage project risks. Shareholders now and in the future demand results, which means that companies must be innovative in how they get their products to market; they must use efficient methodologies, concepts, tools, and techniques.

Project management stands out as the enabler to make this happen. Identify the project management disciplines and techniques you would need to send some people to Mars and back. The answer: You would need them all. The challenge for most project environments, however, is to tailor or scale the methodology so it makes sense for projects of lesser size, risk, and complexity. Additionally, project management methodologies can be thought of as a set of principles and techniques for controlling project risks, quality, change requests, and for capturing any



Figure 1.6: Rationale for considering a methodology.

Strategy versus Methodology



1 2 3 4 5 6 7 8 9 10 [ 11 ] 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101