Category Archives: Enterprise Management Software

How Would a Project Manager affect Software Project

14 Jan, 2010
Written & Translated by Effie Sha
Beijing RayooTech Co., Ltd.

What kinds of role does a project manager play in software project management?

For technical background project manager, most of them are perfectionist, even though they know it’s very hard to reach. Usually, this will cause project postponement, client complaints, products are delayed to goes live, and development team is exhausted. For management background project manager, most of them pay more attention on the progress of project development but they cannot control the hidden risks, such as the mature technology, programmers and technical assignment, etc. It is difficult to control the project when it is delayed and the serious result will be project failure. The above two situations also will happen to someone who know both technology and management.

Than here is the question: How to be a good project manager?

Be Avoid issues

1; Be avoid to manage numerous things to mess up your project
There are frequent requirement changing, team members exchanging in both big and small projects. Too many requirements changing will lead to project out of control even project team work overtime. Finally, you will find there is nothing in perfect and you have to face clients’ complaints, boss will be hot and bothered, team members will be tired.

Definitely, requirement changing and modification by clients or technology issues by programmers are very common during the project progress. So a good project manager should understand these requirements deeply and figure out the right solution in short time. Be aware which requirement can be placed in the first phase and which one can be pushed to the second phase. Don’t’ forget you have the deadline on project contract. The key point is how to complete the project perfectly before deadline.

2; Be avoid too many personalized or perfect requirement
There must be large number of document if your client is a big company, and every conference will be official, all the staff, manager who related with project and even high level leader will attend the conference to discuss their personalized requirement. And now, the most important thing is how to keep your mind clear without contradict their opinions. There is no doubt that your clients are professionals in their area, but you are professional in software project development. Let them know that which personalized requirement can be achieved and which one cannot or will cause serious problems. Always be remembered, do not make any promise quickly, tell them ‘We’ll determine after discussion’.

Suggestions

1; Good working environment
Good communication between team members is very important, no matter it is requirement discussion or technology problems or testing, very one should help each other in order to make sure the project will be met client’s requirement and completed on time. Don’t forget your team is not isolated, you would find documents and reference from your company.

2; Control the project progress strictly
How to control the progress of software project is the most of things that all project managers and companies concerned about. If there is something wrong with the progress, than lots of unexpected things that make you burnt. Therefore, the necessary meetings have to hold, review and organize project work every week to sum up the carried work and the following tasks. In most cases, the discussion of requirements analysis is bottomless pit. Some of them are difficult to achieve, so as a good project manager, you have to keep your mind clear and pay more attention to control the direction of the topic and encourage your team members to express their views. There is an example of failed project: a company got a large scale project more than 1 million. This project has not been completed overdue for half year, company sent all available programmers to participate the project and everyone was exhausted. What was going on? Modules could be written in two months but they had been changed for four or five times, and finally, the requirement had been changed back to the original one. They realized that sometimes some ideas and decisions were just temporary ones.


3; Pay attention to all aspects of project acceptance
The project acceptance review is a formal review between the project team and a client representative. Client verifies the product and supporting documentation delivered by the project meets the requirements and objectives as set out in the software development plan. To focus the project processes on what it will take to get acceptance from your client. The project will never be completed satisfactorily on schedule and within budget without a clear understanding of the acceptance. So make sure the project management plan defined the acceptance process and criteria for each deliverable. To define ahead of time the high, medium and low level issues that the client is willing to go into production with. It can be very hard to let the client to agree that the system is acceptable for production if the criteria are not in place ahead of time. Also please prepare an analysis to determine how many problems are serious, minor, cosmetic, not legitimate, duplicates or caused by test data.

——————————–

Declaration: This article was excerpted from other resources and we do not take any author’s point of view.

[ All rights reserved, reprint, please specify source and the author. Thank you. ]

Reference:

http://pm.csai.cn/manager/201001041419091568.htm

http://it.toolbox.com/blogs/enterprise-solutions/managing-project-acceptance-32360

http://rup.hops-fp6.org/process/activity/ac_pacrv.htm

China Software Outsourcing CompanyDownload ‘ How Would a Project Manager affect Software Project ‘ Article

Did you like this? Share it:

ECM: Tips to Find the Best Solution & Reduce Cost

Over the years, I’ve been involved in a large number of product analysis and vendor competitions with companies looking to purchase enterprise content management. As a result, I’ve noticed a few trends in the decision process that companies undergo and have come to some realizations. The processes are inefficient, time consuming, costly and don’t always produce a solution which addresses the actual needs of the companies’ objectives.

Costly Short-Cuts

Most organizations, for whatever reason, decide that they need an enterprise content management solution and put together a team to find one. Their approach is usually broken down into the following steps:

  1. Investigate the market
  2. Create a list of functional requirements
  3. Participate in Product demonstrations
  4. Issue a Request For Information (RFI) or even a Request For Proposal (RFP)
  5. Create a short list of vendors and products for deeper review
  6. Award a solution

In theory, this is a decent strategy for finding any application for the organization. Unfortunately, companies tend to take short cuts along the way. The following represent some activities that many companies do that result in costly decisions:

  • Investigate the market
    • Companies either do not put the effort into narrowing down all the potential vendors before moving on to the next steps, or they don’t have a clear understanding of what they problems they are trying to solve.
    • Companies don’t take into account all the criteria needed to define a list of potential vendors and products.
  • Create a list of functional requirements
    • Functional requirements are usually very basic and do not reflect current content practices within the organization. For example:
      • Must provide Check-in/Check-out capabilities
      • Must provide a content viewer
      • Must provide search
      • Must provide workflow
    • Functional requirements generated by organizations looking for content management applications tend to leave out integration and infrastructure requirements as well.
  • Participant in Product demonstrations
    • Organizations often invite a large number of vendors to demo their products. Unfortunately, little guidance is given to the vendors, so a “Show up and Throw up” demonstration takes place which does not address the real needs of the customer.
    • Initial demonstrations are typically “Canned” demonstrations. They all look pretty and easy to use; some more so than others. I once told a customer that I would not do a generic demonstration. Doing so would be similar to doing a test drive in a car on a closed track. You never get to see what the car would really do when it gets on the highway.
  • Issue a Request For Information or even a Request For Proposal
    • I haven’t met anyone in the past 15 years who actually likes to create a RFI or RFP and haven’t even met anyone who actually likes to fill one out. Even though these are necessary evils, they are not always designed to reflect the business problems that companies are trying to address.
    • RFPs and RFIs are all too often distributed to too many vendors, usually the same vendors that the organization invited in for generic demonstrations.
  • Create a short list of vendors and products for deeper review
    • The criteria for selecting the vendors tends to be based off of the initial demonstrations and RFI/RFP responses. While these should be the factors, incorrectly performing initial analysis and demonstrations can lead to organizations down-selecting to the wrong products and vendors for their specific business needs.
    • In most cases, a deeper review consists of a more in-depth demonstration of the product. Most companies address specific use case requirements at this point, but even then, the vendors are given time to create a “canned” demo which doesn’t reflect the true level of effort required to meet certain criteria.
  • Award a solution — an unfortunate event happens at this point, a product is selected and a vendor is awarded a contract. I say unfortunate because a broken process up to this point has led to a decision which will produce a broken solution or a working solution that far exceeds anyone’s budgets.

Finding the Best Solution, Reducing Solution Cost

I’ve recommended the following model to companies and have found that, when following these basic tips, organizations were able to find a solution that best matched their requirements as well as minimized the overall solution cost.

1. Define the Purpose

Ask yourself, why do you need Enterprise Content Management, what problems will it solve? Create a detailed list of current issues and use cases that the new solution will have to address.

2. Investigate the Market

Look for vendors and products that specifically address the identified problem areas.

3. Create a List of Functional Requirements

Make sure that these functional requirements are specific to the problems at hand and include future growth and functionality anticipated in the near future.

4. Participate in Product demonstrations

Limit the number of vendors/products to a manageable set. Give the vendors your list of use cases and ask them to demonstrate how their products will address each item.

Don’t allow “canned” demos. Remember, you will want to know how the software will work in the real world. Any demonstration can be made to look pretty and easy, easily getting the end-users excited, but basing a decision off of DemoWare leads to disappointment.

5. Issue a Request For Information or Even a Request For Proposal

Only invite vendors who have demonstrated their ability to meet most of your requirements during the demonstrations. This will reduce the number of responses you have to weed through and allow you to focus on features not easily demonstrable such as architecture and integration capabilities.

6. Create a Short List of Vendors and Products for Deeper Review

Specify an architecture that matches your environment and a detailed list of use cases that closely match the problems you are trying to solve. Invite at least the top three vendors to come on site and install the software and configure it while you watch.

The vendors should run into problems as they perform this. It is important to see how they, and the software, overcome these issues. After the configurations are complete, have them demonstrate the use cases on the systems they built

7. Award a Solution

Base your awards on the RFI/RFP, POC or back-office success, the vendor/software’s ability to overcome challenges, software price and implementation costs.

A Final Note

There is a lot of good information out there and published use cases of how other organizations solved their problems. In addition, a lot of service providers offer software selection services which can help a company make the best informed decision while providing guidance based on years of experience. Use these to your advantage and happy evaluation.

source: http://www.cmswire.com/cms/enterprise-cms/enterprise-cms-tips-to-find-the-best-solution-reduce-cost-010075.php?pageNum=2

Did you like this? Share it:

Five Reasons Why Carbon Management Software is the Next Big Thing

By Christopher Mines at Greener World Media

A new liability is coming onto the collective balance sheet of companies around the world: Carbon.

In the context of increasing awareness of the business and societal risks of climate change, corporate carbon emissions (and the energy consumption that creates them) are becoming a crucial indicator of business performance. And a new type of software platform, enterprise carbon and energy management (ECEM), is emerging to enable companies to monitor, manage, and report corporate carbon emissions, as well as the energy consumption which is their principal source.

Companies have long used software systems to track and manage the movement of assets around the company — people, money, parts and finished goods, and other hard assets like IT systems or furniture. Enterprises buy and maintain sophisticated systems to manage employees (human capital management [HCM]), customers (customer relationship management [CRM]), financial accounting and auditing, materials and finished goods (enterprise resource planning [ERP]), and IT systems and network management.

Now, ECEM systems are poised to join this list of backbone enterprise software systems. Adoption is driven by managers’ desire to:

  • Improve operational efficiency. Reducing energy consumption and related emissions requires running company operations more efficiently. Very simply, lower energy consumption means lower energy bills either per unit of output (relative terms) or in total (absolute terms).
  • Communicate business metrics to stakeholders. A company’s carbon footprint, reduction targets, and progress toward those targets are becoming standard business metrics that the firm must regularly communicate to constituencies including customers, shareholders, employees, and regulators.
  • Differentiate operations, product, and brand. Progressive companies have seized on carbon management and aggressive reductions in emissions as a central element of their brand positioning with consumers.
  • Comply with regulatory mandates. Governments around the world are stepping in to regulate where business and customer pressure is not sufficient to encourage corporations to act on carbon emissions. So large companies — especially heavy-emitters — are facing implementation in 2010 and 2011 of regimes like the UK’s Carbon Reduction Commitment (CRC) and regulation from the US Environmental Protection Agency (EPA) under the aegis of the Clean Air Act.
  • Mitigate the business risks of climate change. Companies are increasingly cognizant of the material business risks that a changing climate will cause (for example, disruption of raw materials supply) and incorporating such risk assessments into their planning and investment plans. In the U.S., for example, the Securities and Exchange Commission (SEC) now requires companies to include assessment of climate change risks in their financial reporting.

To meet these goals, companies need systematic processes that are instantiated in software systems. Retracing the evolution of other process-management software systems, companies are finding that ad hoc activities documented in spreadsheets no longer meet their requirements.

They need a true system of record that cuts across operational or functional silos, taps into multiple asset classes and data sources, creates structured databases of auditable information, analyzes and displays information in a role-sensitive manner, and provides return paths to the assets to enable action and management (see Figure 1 for a high-level sketch of ECEM system architecture).

Forrester calls these new IT systems enterprise carbon and energy management (ECEM), which we define as:

A corporate-wide system of record for monitoring, managing, and reporting energy use and carbon emissions.

Given the multiple incentives and potential rewards for implementing ECEM, it’s no surprise that our enterprise surveys find fast-growing adoption. The percentage of companies that have either implemented or are planning to implement ECEM systems jumped from 25 percent to 45 percent in just 6 months between our Fall 2009 and Spring 2010 surveys (see Figure 2).

These percentages probably overstate the number of companies that actually have an enterprise-wide system in place; what we are finding as we talk with prospective buyers is that companies are implementing systems at a single facility, or for a single set of assets (like buildings) before expanding. And in a number of cases, buyers are experimenting with multiple ECEM suppliers, testing the functionality and maturity of more than one system. If anything, the action is even more frenetic on the supplier side of the market. For the Market Overview research report we completed last year, we interviewed 25 suppliers of ECEM software. And upon publication, we heard from probably 25 more that were active in the market. We are currently completing our 2010 Market Overview, and have found at least 70 suppliers with some form of ECEM product or service offering; we formally interviewed 40 of them for our report.

Not only is the number of suppliers burgeoning, there are increasing connections between the suppliers. Figure 3 shows our work-in-progress mapping of publically-disclosed partnerships and alliances among ECEM suppliers. Some of these partnerships are with other ECEM vendors (those towards the center of our map), while many others are with a wide variety of suppliers of sensor equipment, analytics software, database tools, vehicle fleet-management systems, building automation software, and other related capabilities.

In a future post I will offer some research predictions and our market-size forecast for ECEM software systems; I look forward to your input and comments in the meantime.

Did you like this? Share it: