نگرانی شرکتهای فناوری اطلاعات از آنجا اوج گرفت که ظاهرا بودجهای برای IT در سال آینده در نظر گرفته نشده بود.
دنیای اقتصاد- حوزه فناوری اطلاعات در کشور ما حکایت غریبی دارد. اگر نخواهم زیاد به حاشیه بروم باید به آمار و اطلاعاتی که در روزهای گذشته در جراید و از سوی برخی مراجع پیرامون وضعیت شرکتهای فناوری اطلاعات منتشر شد، اشاره کنم. نگرانی شرکتهای فناوری اطلاعات از آنجا اوج گرفت که ظاهرا بودجهای برای IT در سال آینده در نظر گرفته نشده بود.
قبلتر از آن هم به مراتب اعلام شده بود که شرکتهای فناوری اطلاعات به ویژه نرمافزاریها در وضع بدی قرار دارند و از ابتدای سال دائما در حال تعدیل نیرو هستند. البته به غیر از موضوع تعدیل نیروی انسانی در شرکتهای فناوری اطلاعات، اخباری نیز از تعطیل شدن و بالا آوردن بدهی و متواری شدن برخی مدیران شرکتهای IT منتشر شد.
لیکن داستان غریبی است که در شرایطی که سازمان نظام صنفی رایانهای به عنوان یکی از نهادهای حوزه فناوری اطلاعات خبر از نیاز مبرم شرکتهای خصوصی به حمایتهای جدی جهت حفظ بقای ایشان میدهد. یکی از بخشهای دولتی در راستای ماموریت نامربوط همه ساله خود، امسال نیز عزم سفر به فرنگستان کرده است.
مرکز صنایع نوین که از چند سال قبل به تنهایی بار کمکاری وزارت بازرگانی، مرکز توسعه صادرات و شرکت نمایشگاهی کشور را بر دوش میکشد امسال نیز قصد دارد از طریق مجری انحصاری خود یعنی شرکت ثنارای بار دیگر تعدادی از شرکتهای کشورمان را به نمایشگاه بینالمللی «سبیت» در کشور آلمان ببرد.
غریبی حکایت ما نیز از همین جا شروع میشود. ما نفهمیدیم وضع شرکتهای خصوصی کشور در حوزه نرمافزار با وجود هشدارها و اظهار نگرانیها بالاخره خوب است یا بد؟ اگر وضعمان خوب نیست که جریان خرج کردن پول مملکت در خارج از کشور چیست؟
حتما این چنین توجیه میشود که چون وضع شرکتها خوب نیست به دنبال یافتن بازارهای جدید برای ایشان هستیم. حال یک پرسش دیگر طرح میشود که مگر چند درصد شرکتهای داخلی محصول قابل صادرات دارند؟
بزرگترین شرکت نرمافزاری کشور تا آنجا که شنیدهایم تا به حال حتی یک محصول نیز به خارج صادر نکرده و از همین بازار داخلی خودمان به چنین جایگاهی رسیده است. پرسش دیگر این که بیایید فرض کنیم ده شرکت داخلی محصول قابل صادرات دارند.
باز هم تا آنجا که من میدانم شرکتهایی که قادر به فروش محصول در بازارهای جهانی هستند از توان مالی مناسبی برای دست کردن در جیب خود برخوردارند و اصولا از طریق اعزام نیروی بازاریاب به این نمایشگاهها گلیم خود را از آب میکشند.
اما فرض کنیم از این ده شرکت 5 شرکت هستند که خیلی دوست دارند بدون پول و توان کافی وارد بازارهای جهانی نیز بشوند. تا اینجا هم عیبی وارد نیست و بیشک باید از شرکتهای کوچک برای ورود به بازارهای جهانی حمایت کرد.
اما چند شرکت با چنین مشخصاتی داریم؟ بیایید باز هم فرض کنیم 10 شرکت. باز باید پرسید آیا دراین شرایط ما باید صدها میلیون تومان را به همین چند شرکت تخصیص دهیم و صدها شرکتهای داخلی را هم به امان خدا رها کنیم؟
آیا همه ساله شرکتهای جدیدی به نمایشگاههای خارجی اعزام میشوند؟
آیا تنها راه ورود به بازارهای جهانی صرف صدها میلیون تومان بودجه دولت در سال برای حضور در نمایشگاههای خارجی است؟
از سفرهای پیشین چه توشهای اندوختهایم و تا چه حد چنین حمایتی به افزایش صادرات محصولات آیتی منجر شده است؟
منبع: ایتنا
Summary
A project is a group of activities that produces a unique product or service with a measurable goal. It has a defined start and finish. Project management is the application of tools and techniques to organize the project activities to successfully meet the project goal. A project manager manages these activities.
A project manager needs not only technical knowledge of the product or service being produced by the project, but also a wide range of general management skills. Key general management skills include leadership, communication, problem solving, negotiation, organization, and time management.
Projects have life cycles that are composed of multiple phases. Applying tools and techniques from process groups completes these phases. The five process groups defined by the Guide to the PMBOK are Initiation, Planning, Executing, Controlling, and Closing. The type of organizational structure impacts how projects are managed and staffed. The primary structures are functional, matrix, and projectized. The traditional departmental hierarchy in a functional organization provides the project manager with the least authority. The other end of the spectrum is the projectized organization, where resources are organized around projects, and the project manager has the authority to take action and make decisions regarding the project. The matrix organization is a middle ground between the functional and the projectized organization.
The Systems Development Life Cycle (SDLC), with its distinct phases of Planning, Analysis, Design, Implementation and Operations and Support augments the overall project planning elements. In a new software development project, for example, not only would you utilize highquality project planning principles, but you’d mesh them with the elements of SDLC so you’re assured that the system you’re delivering is adequate and correct for the requestors
The structure of your organization has a great impact on many aspects of project management, including the authority of the project manager and the process to assign resources.
Project managers can often become frustrated by what appear to be roadblocks in moving the project forward. It many cases the root issue is the organizational structure and how it operates. You must understand how your project fits within the organization in order to know the correct approach to resolving issues.
The classic organization structure is the functional organization, as shown in Figure 1.2. In this structure, the staff is organized along departmental lines, such as IT, marketing, sales, network, public relations, customer support, and legal. Each person within a department has a clearly identified superior.
A project that is approved within a functional organization often has silos of work that are completed independently within each department. These silos may even be managed as separate projects.
The typical characteristics of a functional organization are limited authority for the project manager, part-time rather than full-time project resources, and an issue resolution process that must go up the departmental chain of command and laterally to other departments.
Project managers in functional organizations are often frustrated, because they are held accountable for the results of the project, but they have no means of holding team members accountable for project deliverables. The functional manager controls a team member’s salary, bonus, and job rating. You may see some functional organizations that allow project managers input into team member compensation and rating, but the amount of weight it carries may not always be in proportion to the time spent on the project.
A project manager in a functional organization will benefit greatly from developing a good relationship with the functional managers. These managers can greatly influence the success of the project. Often they are asked to provide more resources to projects than they have available or qualified people. Working with the functional manager to resolve these issues is critical.
Another common organizational structure is the matrix organization, which is depicted in Figure 1.3. Matrix organizations typically are organized along departmental lines, like a functional organization, but resources assigned to a project are accountable to the project manager for all work associated with the project.. The project manager is often a peer of the functional staff managers. The project team members have two or more bosses; their functional manager and the project manager(s) they are reporting to.
The typical characteristics of a matrix organization are low to moderate authority for the project manager, a mix of full-time and part-time project resources, and better interdepartmental communication. There are both weak and strong matrix organizations: the stronger the matrix, the more authority for the project manager.
Project managers in a matrix organization need to be very clear with both the project team members and their respective functional managers which results the team member is accountable for to the project manager and which are accountable to the functional manager. The team member should only be accountable to one person for a given result to avoid conflicting direction. Another trouble area in a matrix organization is how thin resources may be spread. If you have a resource assigned 50 percent to your project, it should be reflected in the work assigned by the functional manager or other projects to which the team member has been assigned. Addressing resource issues up front will prevent problems down the road.
The last type of organization structure we are going to discuss is the projectized organization, which is depicted in Figure 1.4. This organization is far less common in our experience than the other two. In this type of an organization, most of the work is project work, and the company is organized by projects.
The typical characteristics of a projectized organization are a high level of authority for the project manager, full-time project resources, and a dedicated project support staff.
Project managers in a projectized organization are responsible for all decisions regarding the project. Team members are usually colocated, which enhances communication and efficiency.
The big drawback of a projectized organization is the how to handle staffing as one project ends. There may not always be a new project waiting for resources. The timing of increasing or decreasing resources can become very complex
Every project has a number of phases to mark the beginning, middle, and end of the project. The project life cycle is the composition of these multiple phases, which can be laid out on a timeline. In an ideal world, all deliverables from one phase would be complete and approved prior to the start of the next phase. In reality, the various phases of a life cycle can overlap. The term for starting one phase prior to the completion of a previous phase is fast tracking. This is normally done to shorten the project schedule.
Project life cycles vary widely between different industries and to some degree even within an organization. Although project life cycles are diverse, you will find several key elements. A project life cycle should depict at the highest level the deliverables for each phase and the category of resources involved. A life cycle should also depict how the project will be folded into the operational business on completion.
Now let’s take a look at some examples of typical life cycles of IT projects.
Every IT project has a life cycle and a series of phases. The software development life cycle (SDLC) closely parallels project management process groups with its five phases: planning, analysis, design, implementation, and operation and support. The following is a closer look at each of these phases.
The systems planning phase begins with a formal request to IT for a system that will solve a problem, or provide an upgrade or improvement to an existing system. The formal request is called a systems request and embodies the problem and business processes that need to be addressed within the given system.
A systems request has two potential outcomes: a preliminary investigation and a feasibility study (depending on the size of the system). The preliminary investigation basically maps to the preliminary requirement-gathering process that you go through when you’re in the Initiation process group of project management. From this preliminary investigation you may derive a feasibility study that denotes the cost-benefits associated with the request as well as recommendations that drill down into the various factors involved, such as operational, time, economic, or technical conditions.
But systems planning goes beyond the notion of “we’ve got a system we’d like for you to build.” It also gets into the idea of how that system fits into the overall corporate scheme of things—does the system enhance the corporate vision and goals?
Additionally (and more subtly), good systems planning may well point back to the need for a change in business processes in order to more closely accommodate the stated desired results. Sometimes automation and technology can’t (or shouldn’t) solve a problem, when a change in the way that a business process is currently being done will do nicely.
You’ve solidified a feasible system request and you’re planning on going forward. The systems analysis segment is the next logical step in your progression. In this phase you develop a logical model of the system by diagramming the logical flows of the data. You’ll map out what the requirements are for the new system.
Note |
Some good system analysis techniques (but beyond the scope of this book) include data flow diagrams (DFDs) and use case scenarios and entity relationship diagrams (ERDs) that illustrate the various inflows and outflows of the system, in addition to the anticipated way that people will interact with it. |
If you understand the goals of the business manager that is requesting the system and you couple that with the logical flows that you derive for the system by going through a business process analysis, you can make your job much easier in diagramming, at a high level, how the proposed new system will operate. A visual representation of the basic business flows will also help others understand how the system parts interoperate and help nontechnical people understand how you think about their business process.
In the analysis phase you begin to knock out what it is—the nuts and bolts—that this system consists of. Through your previous analysis process, including interviewing various stakeholders, performing fact-finding analysis, and formulating solid objective ideas about what the system should be comprised of and what it should do, you can build various enterprise models that include the data objects themselves. You also can understand the various process and data models that are involved. Also, fleshing out a prototype at this point will prove to be a worthwhile effort because prototypes give stakeholders a way to visualize the new system.
The systems planning and analysis phases roughly correlate to the Initiation and Planning process groups, which we’ll discuss in more detail in Chapter 2.
The final outcome of the systems analysis phase is called a systems requirements document. The document spells out what you heard the business representatives say that they wanted in the new system. You got here by going through a variety of processes including interviewing various experts in the business process, sitting with them to watch how they go about their work, questioning the manager, and other such methods. The document is about the business for the business. Like a da Vinci charcoal drawing intending to help the artist understand what it was he was going to paint, the business requirements doc will help you derive your new system.
In the systems design phase you denote all the components that will be included in your IT project, including all of the inputs (such as data flowing into the system or keyboard input by a data-entry clerk), outputs (such as screen displays or reports), and processes involved. Additionally, at design time you flesh out the various controls required, whether automated or manual, that will contribute to the system’s successful operation. If you’re working on a project in which code has to be written, you’ll draw out the architecture that the application(s) will use in a document, called the system design specification (SDS), a detailed document that allows the project team members to exactly build the desired system. The SDS illustrates exactly how programmers are to create the system.
If the system doesn’t require software development, but does require database or infrastructure creation or enhancement, it’s key that all stakeholders, from management to end users, understand what you’ve designed and how you imagine it will work, and that technicians be able to build the desired system. If you’re using a Commercial Off The Shelf (COTS) program, you’ll design its integration into the system that you’re building.
Note too that other elements such as infrastructure additions or renovations, cabling upgrades, WAN connectivity (including wireless), new types of computing such as PDAs, telephony integration, and a host of other things may be included in the design of your system. Just because your system primarily uses software does not mean that the underlying components don’t need to be addressed and freshened as well.
In the systems implementation phase of the IT project life cycle, the system is constructed. Whether that means that programmers write programs, you purchase COTS programs, or you come up with some in-between system that uses elements from both worlds, you’ll want to deliver a completely functional and fully documented system.
This phase includes such elements as the conversion of old data to new tables, training the users, testing, and migrating to the new system. You’ll also prepare a write-up called the systems evaluation to provide an earmark as to how well the system performs relative to your stipulations in the system design specification.
Mapping somewhat to the Closing process group, which we’ll discuss in just a moment, the systems operation and support phase means that you put the system into routine operation, and provide a method whereby the system can be supported if there is trouble. However, the operation and support phase goes beyond Closing in that it calls for elements such as change management where you have maintenance or enhancements that need to be performed and you provide for some modicum of scalability in the system, should it need to be added to later.
You need to know two other things as a manager of projects in the IT project life cycle: setting milestones and checkpoints. Let’s discuss this further.
Let us mention here another type of document that you might want to consider when you’re meshing two management methodologies together (i.e., project management and the SDLC): the Project Concept Document. At initial requirements-gathering time, the systems analyst will generate a document that contains the high-level requirements she discovered upon examining the customer request. This document could act as a starting point in the project planning process as well. A systems analyst may not be a project manager, or may be—it depends on the way your company is laid out and the complexity of the project before you. But we know that good quality systems analysis and design leads to high-efficiency systems, especially when built under a well-developed project management paradigm. A starting-point document for both players—the project concept document—is an ideal way to flesh out the skeleton of the project and get the two parties talking.
Note that the systems analyst will go on to develop some very elaborate flows out of her initial requirements—the project manager must be in lockstep with the elements being worked out.
Any good SDLC process should include the milestones on which you see the project pivoting. For example, perhaps a significant milestone for an e-commerce project would be the purchase, acquisition, installation, configuration, and deployment of the web servers that will be used for the system. A very discreet set of tasks are needed in order to accomplish this milestone. At its accomplishment, in the systems design world, we’d step back and ask project stakeholders such as the managers and technicians to give us a go/no-go decision regarding whether the project should move forward.
Additionally, in between milestones, good projects include several checkpoints along the way that reveal whether we’re on time and within budget in our project. A prudent number of checkpoints (not too many to be burdensome) can reveal the pulse of the project at any given point.