Project Team Blog

Customer-driven project management uses the voice of the client as a guide at every turn of the project’s life cycle to achieve optimum quality.

Project teams that put the interest of their clients are assured of repeat businesses and long-term relationships. They know that at the end of the day, their processes and methodologies are established to meet clients’ expectations. And meeting clients’ expectations hopefully means satisfaction.

It has always been the goal of project teams to complete projects on time within cost and fulfill quality criteria, but it has often been the case that when projects are implemented, project teams focus on their tasks more and lose sight of their relationships with clients. Now, thanks to the current dynamics of an increasingly demanding business environment, the management concept of too much organizational and process control that on many occasions resulted in alienating customers is slowly giving way to a marriage of disciplined process implementation and customer satisfaction. And by satisfaction, it means giving more than what is required.

Customer-driven project management uses the voice of the client as a guide at every turn of the project’s implementation process to achieve optimum quality. According to Bruce T. Barkley and James H. Saylor in their book Customer-Driven Project Management (2001), this management approach involves the following items, which we expand to meet the more complex needs of today’s client-supplier relationships:

Customer-driven project management does not veer far from many project management approaches. However, client leadership and continuous improvement through the team’s feelings of ownership of the project spell the difference between just finishing tasks and pleasing the customer. 

By ExecutiveBrief
Technology Management Resource for Business Leaders
http://www.executivebrief.com

As business needs help set IT’s priorities, how IT departments align their solutions with business objectives hinge on a number of success factors.

The most pressing issue among CIOs, according to a 2008 survey by Society for Information Management (SIM) is the alignment—or misalignment—of IT with business. As IT departments need to consolidate their resources, there is a growing concern among CIOs that doing so may not be so easy. One cause of this issue is that tech workforces are seen as merely solutions provider instead of as strategic resources to achieve business success. Meeting business expectations effectively should be the goal of IT, but more importantly, of business

There are several approaches that can be taken to align IT with business. Some approaches focus on the roles of individual IT contributors, while others focus on the needs of the business side and their position in the market. It is up to CIOs to identify key business needs and turn these needs into objectives that their IT organizations must achieve. CIOs also have the responsibility to build organizations that can deliver the right support to various project portfolios.

IT departments are there not just to provide computing solutions. Businesses will get more value from IT by considering their operational and strategic business needs. As business requirements help set IT’s priorities in terms of identifying resources, form insourcing and outsourcing strategies, and set up infrastructures, how IT departments implement their chosen approaches hinge on the following success factors:

• Open communication lines. IT departments and their business counterparts should set up a communication system that actively involves all stakeholders. This allows IT to get a feedback from the business side to formulate the best solutions possible; on the other hand, an open communication line with their technical counterparts familiarize business decision-makers to identify and take advantage of the available technical knowledgebase for better organizational and market performance.
• Business requirements analysis. IT’s exposure to business allows them to identify business needs that should be the key drivers behind most aspects of their operations. CIOs are best positioned to frame projects, infrastructures, and systems according to the needs of their primary clients. The success of IT as a business strategy is judged on how it helped in meeting business objectives.
• Expectation management. Both sides should be realistic about their expectations of each other. This can be achieved through the two mentioned success factors: communication and requirements. Business managers should know the limitations of IT, and that solutions do not come in cheap, such that in-house resources for application development and maintenance may require engaging third-parties to fulfill business needs. On the other hand, IT should be aware of the technical—and sometimes, financial—limitations of business operations. For example, introducing new systems to the IT enterprise landscape means training batches of end-users which then result in additional work to include end-user documentation and training designs.
• Organizational protocols and sponsorship. Internal protocols do affect the success of IT-business alignment. Sadly, protocols do not necessarily mean processes; protocols in most traditional institutions mean “just how things are done.” To navigate through layers of bureaucracy where it exists is to identify key personnel and project sponsors who understand and can articulate the justifications for IT projects as business strategies. Where all decision-makers must stamp their signatures in all IT ventures, CIOs should find the right people to champion their causes through coherent analyses of business needs and presentations of business solutions and the hoped-for success criteria.

At the end of the day, most of the work rest on the shoulders of CIOs, being the key figures that understand the business side of things and have the ability to translate business needs into technology solutions.

By ExecutiveBrief
Technology Management Resource for Business Leaders
www.executivebrief.com

�

Whatever the economic realities may be, technology is an integral part of majority of business operations the world over. How do you maintain your tech-reliant operations in the midst of a challenging business climate?

Most global businesses depend on technology and business partners to run their operations smoothly while improving margins. In all economic climates, businesses that engage the specialization of the best technology and service providers are also best positioned to establish their brands and build customer loyalty. In the first place, what they can save on support operations and product development can be re-invested in improving market reach and further innovation.

So how can business leaders maintain their tech-reliant operations going and remain profitable? By recession-proofing their IT operations. Here are some of the steps:

1. Adopt business intelligence smarts. Any enterprise that has a significant IT workforce or is engaged in technology services knows the importance that data consolidation—or metrics—plays in the success of a product, a service, or of the enterprise. These numbers are the most reliable way to look for trends, medians or any deviations from the norm, and upon which big decisions are made. Consolidate your data.  Get a business intelligence system that allows for easier data collection and consolidation, and reports management.

2. Consolidate technologies. Technologies should help the enterprise conduct its business, not get in the way of productivity, and more so, of profitability. Due to the sheer size of their operations, many large enterprises employ multiple applications and systems to conduct almost the same services.  Are you using multiple content management systems when one will be enough to handle firm-wide communications? Do you record your project hours separately from your timekeeping application? Is your ERP system composed of too many modules run by too many vendors? Maybe it’s time to let go of some of your clunky systems that take too much time and effort to maintain, update, and consolidate. Opt for the best solutions that can serve the enterprise’s most important and only necessary computing and communication needs.

3. Go virtual. SaaS, cloud computing, and virtualization are some of the most popular buzzwords this year, thanks to businesses finding new ways to trim IT budgets without necessarily trimming operations and lowering the quality of their services. Barring security breaches, software-as-a-service is the option for small and medium size enterprises because of its speed of implementation and flexibility for small- to medium-scale operations. Cloud computing, on the other hand, is a by-product of Web 2.0 practices and excess computing and storage capacity. Lastly, thanks to the global scope of many enterprises, virtualization is not just a buzzword but an operational reality among many project teams, service providers, and even top-level executives.

4. Standardize processes; adopt agile methodologies. Time, money, and your clients’ patience are finite resources.  Work with a service provider that can help you at every stage of product development–from requirements gathering, to product or technical design, to development, to implementation, and to product release. Choose a service provider that specializes on agile development that allows for incorporation of improvements at every release of the product whether it is meant for the outside market or the organization’s internal operations.

5. Outsource, and outsource intelligently. Don’t just engage a service provider, whether offshore or nearshore, based on cost-savings alone. Look for long-term benefits from a combination of cost-savings, technology savvy, methodologies, consulting skills, and management culture of the vendor.

By ExecutiveBrief
More at: www.executivebrief.com

While SaaS has been gaining popularity recently, it is remarkably noticeable that its popularity is still limited mostly to small and medium-size businesses. Larger enterprises are still reluctant to embrace hosted application for their IT needs.

According to a recent Forrester Research paper, “The Truth about Software as a Service,” which is a result of a late 2007 survey of IT decision-makers from North America and Europe, only 16 percent of respondents are using SaaS applications. On the other hand, 80 percent are still reluctant to adopt SaaS. Of the 80 percent, only 47 percent expressed interest, while 37 percent were “not interested at all.”

If SaaS has been gaining popularity recently, the gap between big-business IT decision-makers who were interested in it and those who were either partially interested or totally uninterested is too wide.  As if to counter the SaaS advantages that were cited in the previous blog, researchers and tech workers in big enterprises cite various reasons why it is not being widely adopted outside the realm of SMBs. 

One of the top reasons why big businesses are reluctant to adopt SaaS is business continuity. Put simply, the market’s atmosphere is fraught with uncertainty that SaaS vendors could just shut their doors easily. When it happens, where do the hosted data go? What alternatives are immediately available to end-users?

Next to business continuity, data security, vendor lock-in, and accountability are some of the issues that clients — both large and small or medium-size businesses — raise most of the time. Because many large enterprises are sensitive about their company data, they are reluctant to hand company information to third parties. In terms of accountability, there have been complaints about vendors’ dishonesty about real downtime rates and the speed with which they address it. If a service is suddenly cut off, IT departments ask how long it takes for the service to be available again and what kind of assurances are provided to address such issues.

SaaS are typically fit-for-all, so customization is another nagging issue. Maybe small businesses’ IT needs are not complex, that is why they are more willing to sign up with SaaS vendors. On the other hand, enterprises that provide more than one type of service, sell more than one product, are present in different locations, and employ thousands of employees have IT needs that are as complex as their multinational presence and multiple businesses. That most vendors do not offer customizable services to match big businesses’ needs is one of the signs that it is still in its infancy.

Related to downtimes is the issue of scalability. Can a hosted service support thousands of users who access the application simultaneously? If it cannot, can a business enlist the help of another vendor? This is where the issue of interoperability and portability also come in. In most cases, transferring data from one SaaS provider to another takes time and considerable effort.

That SaaS became popular among SMBs means it is promising. However, this promise does not translate well in big business so far.

By ExecutiveBrief
www.executivebrief.com

Has your company developed entirely new software or added to software already in use throughout the organization and found the process cumbersome, frustrating, and sometimes not living up to expectations or meeting organizational goals?  If so, the solution to a smooth and effective development program may be as easy as staffing a well-qualified project manager and adopting a proven development process.

Developing a Practical Approach: The Role of the Project Manager

When undertaking a software development project, the first element to consider is the establishment of a comprehensive yet practical approach to the initiative that ultimately will lead to a successful end result.

The in-house project manager has a key role in ensuring each phase of the project is carried out as planned. The project manager is responsible for considering the potential risks involved with the project and how to avoid and resolve them, establishing and maintaining momentum throughout the project, ensuring individual project team member tasks are assigned appropriately and carried out according to specifications, and successfully addressing and resolving any conflicts that may arise during the length of the development project.

A well-qualified project manager is able to address what may seem to be an overwhelmingly complex process by developing an organized approach where the process is broken down into manageable individual tasks and understanding how to keep those involved in the project dedicated to the ultimate goal of meeting and even exceeding the expected end result.

Embarking on the Initiative: Key Steps to Consider

With a comprehensive approach and a competent project manager in place to guide the new software development initiative, there is another important element your organization may find helpful as you embark on the project: establishing specific steps that can be followed to project completion that are based on proven industry experience in such a project environment.

Two renowned experts, Dr. Gordon Scott Gehrs and Dr. Dorota Huizinga, single out nine key steps to consider as you embark on a software development project:

Step #1: Conduct Feasibility Analysis

Full article, presenting in detail these key practical guidelines to approach a software development project, is available at: http://www.executivebrief.com/article/9-steps-to-a-hassle-free-and-effective-software-development-project/

By ExecutiveBrief: http://www.executivebrief.com

Some of the most common reasons why change requests are made.

Change requests alter the course of a project and working within the constraints of time, budget and quality more challenging. If change requests are not handled properly, the project will overshoot its schedule and accumulate costs that are beyond the original plan.

Realize that change requests are not made because people in your team, the project sponsors, or clients cannot make up their minds. Instead, most requests for changes are made in order to improve the project and, in some cases, the process of implementing the project.

Changes are inevitable during the course of the development lifecycle, and there are various reasons why changes occur. Some of these reasons are technical, some are procedural, some are financial, and still some are political or people-related.  Whether a project manager supports the adjustments or not, it is important to think over why changes are requested and their possible impact on the integrity of the project, as well a the delivery process. Let us look at the most common reasons why changes occur.

Incomplete requirements

Scope changes –or creeping functionality–are the results of ineffective management of requirements.  These are also the results of a project manger’s inability to get approval from project sponsors. When requirements kept going through changes during the course of a development lifecycle, new features and functionalities are often added, resulting in a product that overshoots the allocated time and resources, but fails to meet an acceptable level of quality.

Organizational restructuring

If the client’s organizational structure changes midway through the project lifecycle, it is inevitable for the delivery team to expect either a closer scrutiny of the project or change requests to be submitted. Financial considerations, corporate policies, and new sets of end users are some of the factors to consider as change agents when organization restructurings happen. Some requirements are too rigid, while some requirements need more room for discrepancy in specifications.  When alpha releases prove to be too limited to one set of target users alone, then expect change requests from auxiliary end-users.

External factors, such as new vendors, technologies, or methodologies

External factors, such as the involvement of another vendor or a representative end-user, can cause diversion from the original project execution plan. This issue is often as technical as it is financial (or political). Ideas that are tied to the new vendor’s methodologies and technologies can affect the execution of the project plan halfway through the lifecycle.  Sometimes, clients can be finicky about what they want out of the project that agreed-upon requirements kept getting changed. The more a finicky client gets in contact with vendors who want to take on the project, the more ideas they get about “improving” the product and cutting the cost of development. In such a scenario, be prepared.

By ExecutiveBrief: www.executivebrief.com

�

I suppose it goes without saying, but with a down-economy, now’s the time to bill clients for every hour you’re entitled to.  And to watch your resource utilization more closely.  Below are some areas to watch for.  Consider a product like Standard Time® to make them happen.

Resource Utilization
Resource utilization is the percentage of billable hours your employees are working.  Let’s say there are 172 billable hours in a give month (every month is different).  And let’s say Fred only worked 45 of them, and Angie worked 100.  The utilization rates would be 26% and 58%.  Not great, but workable.  Can you make money at those rates?  Well, that depends upon employee salaries and overhead.  Increase your utilization rates, and you win.  The image below is a report of utilization rates.

Utilization Rates

Correct Billing Rates
For every hour you bill clients, you have a billable rate.  Those rates depend upon employee skillsets, and the tasks performed.  Research and Development will naturally bill out at higher rates than travel and meetings.  I recommend using Standard Time® to monitor those rates for each employee.  Make sure you’re billing at the correct rates, and for every hour your people are employed.

Communications and client Login
Clients like to see what you’ve been up to.  Without a client login into your time keeping software, they aren’t certain what’s being done on their projects.  They begin to wonder.  Give them a client password, and let them peek into their own projects.  It will aid in your communications efforts.  Communications is everything in client relations.

The folks at Standard Time can demonstrate all these areas:  Give them a ping!

–ray

Every company needs specialty tools to make their company run - little things to help make things easier.  For example, a cabinet shop might need custom-built jigs.  An auto mechanic may build a few of his own tools for jobs he performs frequently.  High-tech companies certainly build plenty of in-house programs to manage information technology - databases, data entry, customer records, etc.

The question I’m posing is this: when is it right to build those custom tools in-house, or when should you go out and buy a suitable tool instead?  For instance, should an auto mechanic build his own 500 piece wrench set, or go down to Sears and buy them?  Should a tech company build a time tracking product from scratch, or license something like Standard Time®?

Since I’ve personally worked in consulting for a number of years (in another life), I’ve seen it all.  I’ve seen companies build products that were available off-the-shelf for 1/100th of the cost.  And, I’ve seen people shoehorn freeware code and products into commercial use.  Both were mistakes.

I tend to say that companies should only build products that are much more expensive to buy.  In other words, don’t try to write your own compiler - Microsoft does that just fine.  Another reason to build is when you have exotic business needs.  One last reason might be if you have time on your hands.  If you’re not making money serving customers, maybe you’ll have time to write and maintain a few necessary tools.  But that’s a dangerous position to be in.

In IT, we ignore such advice because we know we can build everything.  But I suppose the mechanic with a little metal-working and welding experience does the same thing. 

What tools have you built, and regretted it?  Post a comment and let me know!

–ray

Ever wonder why there are so few product-based companies, and so many service-based ones?  It’s all about cash flow.  The images below illustrate this, but they need some explanation.

Product-based companies
If you’ve got bright ideas of building a product and making lots of money, think again…  There’s a long pipeline from product development to big piles of sweaty cash.  First, you have to build the product.  Nobody’s paying you to do that.  It’s your nickel, pal.  And you can spend as much time as you like.  But then comes marketing and promotion.  Get it out there for the world to see - but still more time without pay.  And then, when they find your product, you’ve got to sell it and collect your reward.  It can take months or years.  And it can be exhausting.  See the stages below.

Service-based companies
Want cash quick?  That’s why there are many more service-based companies in the world.  In that model, you can find a client and begin invoicing them after the first thirty days.  The path to that stack of sweaty cash is much shorter.  But, the stacks are smaller.  And, you tend to live on them so they never accumulate.  Lose a client, and you’ll have to start over.  Even this model has it’s risks.

So which model suits you?  Got the time of invest and wait for the “big” payoff?  Or, do you prefer earning as you go along?  There are plenty of advantages to both, and only you can decide what’s right for you.  Hopefully, this short post will help in your decision-making process.

–newshirt