Archive for the 'Advice' Category

Jul 13 2009

7 Things You Need to Know About Development Project Estimations

Whether you are a project manager planning for a smooth implementation of a plan or a project sponsor on whose decisions a project depends, you cannot escape from the fact that project estimation is essential to its success. In the first place, there are three basic requirements that a project must satisfy: schedule, budget, and quality. The need to work within these essential project boundaries poses a huge challenge to everyone in the central management team.

There are various aspects that affect project estimates, such as team skills and experience levels, available technology, use of full-time or part-time resources, project quality management, risks, iteration, development environment, requirements, and most of all, the level of commitment of all project members.

Moreover, project estimations do not need to be too complicated. There are tools, methodologies, and best practices that can help project management teams, from sponsors to project managers, agree on estimates and push development efforts forward. Some of these include the following:

  1. Project estimates must be based on the application’s architecture. Making estimates based on an application’s architecture should give you a clear idea of the length of the entire development project phase. Moreover, an architecture-based estimation provides you a macro-level view of the resources needed to complete the project.
  2. Project estimations should also come from the ground up. All estimates must add up, and estimating the collective efforts of the production teams that work on the application’s modules helps identify the number of in-house and outsourced consultants that you need to hire for the entire project, as well as have a clear idea of the collective man-hours required to code modules or finish all features of the application. Ground-up estimates are provided by project team members and do not necessarily match top-level estimates exactly. In this case, it is best to add a percentage of architecture-based estimates to give room to possible reworks, risks, and other events that may or may not be within the control of the project staff.
  3. Do not forget modular estimates. Once you have a clear idea of the architecture, it becomes easier to identify the modules that make up the entirety of the application. Knowing the nature of these modules should help you identify which can be done in-house or onshore, or by an offshore development team. Moreover, given the location and team composition of each development team that works on a module, it becomes easier to identify the technical and financial resources needed to work on the codes.
  4. Development language matters. Whether the development language is Java, .Net, C++ or any other popular language used by software engineers, team that will be hired for the project must be knowledgeable in it. Some development efforts require higher skills in these languages, while some only need basic functional knowledge, and the levels of specialization in any of these languages have corresponding rates. Most of the time, the chosen development language depends on the chosen platform, and certain platforms run on specialized hardware.
  5. You cannot promise upper management dramatic costs from offshoring. While there are greater savings from having development work done by offshore teams composed of workers whose rates are significantly lower from onshore staff, you must consider communication, knowledge transfer, technical set-up, and software installation costs in your financial estimates. Estimating costs is often more about managing expectations, but as the project matures, it should be clearer whether the money spent on it was money that was spent well.
  6. Project estimation software and tools help identify “what-if” scenarios. Over the years, project managers have devised ways to automate project schedule, framework, cost, and staffing estimates. Some estimation applications also have sample historical data or models based on real-world examples. If your business has a lot in common with the samples in the estimation tool, it can help you identify what-if scenarios and in turn include risks, buffers, and iteration estimates.
  7. Price break-down helps in prioritization. Breaking down the total cost of the project helps management decide which parts of a system should be prioritized, delayed, or even cancel. Estimating costs for a new project may not be easy, but project sponsors and managers must be able to know and agree on the breakdown of costs of development, technical requirements, and overhead.

By ExecutiveBrief -online resource on process management, project management, and process improvement.

No responses yet

May 28 2009

Success Factors in Knowledge Management

Knowledge management professionals must keep in mind that KM’s explicit end-goal is profitability while its implicit purpose is to empower participants through intellectual platforms and processes that promote learning and practical knowledge.

Knowledge, without a doubt, plays an important role in the success of any organization. In fact, in order to maintain a competitive advantage, modern organizations incorporate knowledge creation, knowledge sharing, and knowledge management into their business processes. The mere survival of many organizations hinges on the strength of their capabilities; moreover, companies form decisions based on their relevant knowledge of their business landscapes.

Thanks to developments in information and communication technologies, it is now easier to develop, store, and transfer knowledge. This capability is particularly true among organizations with global workforces. After all, international competition and globalization are the driving forces behind most technological innovations, and companies quickly take advantage of these developments when it comes to managing the creation and flow of information.

“Ultimately, leveraging relevant knowledge assets to improve organizational performance is what knowledge management is all about,” says Murray E. Jennex in his book, Knowledge Management in Modern Organizations (2007). However, in spite of the lightning-speed creation of new knowledge and the improvements in communication technologies, many organizations still find that their knowledge management practices are lacking. Specifically, within client-consultant relationships, knowledge transfer does not always translate into better performance by all project team members, nor does it always translate into the successful delivery of projects.

To be successful, knowledge management programs require more than simply conducting training sessions or transferring knowledge. Practitioners must always remember that KM’s explicit end-goal is profitability - while KM’s implicit purpose is to empower participants by providing them with the intellectual platforms and processes that promote learning and practical knowledge.

Here are a few factors that contribute to successful knowledge management initiatives:

  • Linkage between knowledge and economic performance – Knowledge management exists because it enables the organization to reach its business goals. Otherwise, there is no point in putting together all the best practices, tacit knowledge, and skill sets in a cohesive system that is accessible by all parties - when and where they need it. As business increasingly becomes more global, the competition for greater market share depends on the capabilities of its players to a certain degree. KM practitioners must be able to identify the business value of knowledge management in their organizations - whether it is to manage projects, provide back-office operations services or to give ideas on how processes can be better optimized - among others. In most consulting relationships, knowledge is the currency by which all transactions are made.
  • Setting and communicating clear objectives for specific organizational or project levels – Heather Kreech, the Director of Knowledge Communications of the International Institute for Sustainable Development has some specific ideas on this very subject. In her paper, Success Factors in Knowledge Management (2005), she states that knowledge-sharing works best when knowledge managers “gather and communicate knowledge at the project/activity/field level before [they] begin to aggregate up to corporate systems and general knowledge marketing strategies”. Having a specific organizational level or project group in mind, results in better designed knowledge management systems, training programs, and tools that can meet the specific needs of workers.
  • Having the appropriate systems and infrastructure – Ideally, knowledge is created, processed, stored, and archived. Managing the process of creating knowledge, communicating this knowledge to participants, and making knowledge available to anyone in the organization, means that an organization must have the right communication systems and data storage facilities. However, it is not enough to simply store knowledge as this knowledge must be found whenever it is needed. Thus, the availability of internal search facilities and computer-based training programs is critical.
  • Having the right champions – KM initiatives need project and process champions who can rally the support of everyone - from top management down to individual staff members. Having management support can result in the freeing up of resources - such as financial, expertise, and infrastructure - all of which are critical to the successful implementation of KM projects. Financial backing means that KM managers can implement training programs, hire both internal and external specialists - as well as acquire the required infrastructure to manage training programs. On the other hand, access to experts from either within or outside the organization, means better identification of knowledge gaps and training requirements, and more importantly, engineering training and communication programs that meet the said needs.

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

No responses yet

May 06 2009

Vicarious Goal Completion

Published by raywhite under Advice, project management

Bear with me…  Vicarious Goal Completion is a pretty obscure title, but there’s logic to it.  :)

Psychologists have observed a strange human peculiarity.  And it relates directly to project management.  It’s called Vicarious Goal Completion.  Researchers first encountered it while studying fast food menus.  Can I get you to bite?

When fast food menus contain a “Salad” choice or other healthy food items, people purchase the junk food instead! 

Here’s why: People who see healthy items on a menu feel good about their weight loss goals and give themselves permission to indulge a little.  So, they eat the burger and fries instead.  In other words, they remember eating good and believe they have already attained their goals, so that gives them permission to splurge.  The goals are completed vicariously through the menu itself.

Obviously, this is just a slick way of tricking oneself into dodging responsibility.  They used to call this laziness.  Any excuse to pig out.

I’ve notice the same behavior with software downloads and project tasks.  The ratio of downloads to form-completions is pitifully low.  In other words, people take the time to fill out a download form, but never actually install and test the software.  Vicarious Goal Completion!  The person believes they have finished the job, when in fact, they have only just begun.  Filling out the form gives them a warm fuzzy feeling about the goal of procuring software, and that warm feeling is enough to satisfy them.  They don’t actually care if they download, install, and test.  They have met their goals and that’s all that matters.

The same is true of project management.  Beware of employees who start tasks, but never complete them.  Once a task is started, good feelings arise.  Those good feelings give the employee permission of quit because they feel they have already finished, or full completion is within sight.  Vicarious Goal Completion!  Nobody likes to take their project tasks to the uttermost level of completion - unless forced to do so.

 

–ray

No responses yet

Apr 15 2009

Technologies that Matter in a Slow Economy

Bare-bones hardware and software, and all things virtual dictate the game of computing in a slow economy.

A recent advertisement by Microsoft caused a stir among the Mac-loving community of tech workers. The ad shows a flame-haired Lauren looking for a 17-inch laptop for under $1,000. The challenge is that if she finds one that meets her specifications, she gets to keep the laptop and the change from the $1,000. And so she first goes to a Mac store where the only thing that falls within her budget is a 13-inch Macbook. Slightly dejected, she drives off and along the way says the line that struck a raw nerve among Mac fans and probably Apple itself: “I’m just not cool enough to be a Mac person.”

She enters another computer store where she finds two laptops that meet her needs on top of her 17-inch monitor requirement for only $699. The ad ends with the line, “I’m a PC and I got just what I needed.”

Ever since the TV spot came out, the Mac community has been up in arms, dismissing all things PC and the operating system that most of the time goes with it. However, pundits believe that no matter how “cool” Mac may be, the deciding factor for buying PC is price point. When things are tough and everyone is worrying about their finances, notwithstanding the availability of disposable income for some, people are conscious about the amount of money they spend on technology.

The same is true whether one is buying technology services, software, or hardware. As the world gets on with the current crisis, technology is responding at rapid speed to manage the needs of individual and enterprise tech buyers everywhere.

So what are the technologies that actually matter in this climate? Here are a few:

Virtualization - Video conferences, virtual meetings, and screen sharing are just a few of the ways the tech world is replacing bricks-and-mortar or traditional modes of conducting daily business. Virtualization makes it possible for workers to overlap work schedules across different time zones and collaborate on projects that are stored in different parts of the globe. Moreover, telecommuting becomes a trend even–or especially–among large enterprises who benefit from lower overhead costs and thankful workers who are happy to skip daily commutes and save on gas. Who needs to be physically present at the office when you can access your virtual desktop hosted by an outsourced data center?

Cloud Computing - Technology suppliers, from Microsoft to Sun to Amazon to startups, have embraced cloud computing as the next wave of business technology service. Buyers need applications and services that can be deployed as soon as possible and with as little maintenance required. Cloud computing also eliminates the need to build armies of engineers to create applications that can be “rented” anyway.

Enterprise Telecommunications - Businesses are getting savvier when it comes to enterprise communication, that any meeting, conference, or messaging that can be done via BlackBerry, VoIP, or company-supported IMs is welcome. Those that can invest in infrastructure requirements to put these technologies in place for two reasons: (1) to minimize the cost of or need for business travel and (2) to facilitate seamless communication among workers from different locations.

Open-Source - In early February, the British government released a policy that emphasized preference for open-source over proprietary software in order to cut down cost on technology spending. With proper due diligence, the move is surely to be copied by various industries everywhere in the quest to manage operating costs while remaining productive and responsive to customer demands.

Bare-Bones Hardware - The popularity of netbooks can be attributed to its portability, and a more so to a much friendlier price point. As software and file management move to the clouds and storage becomes cheaper, tech buyers, such as Lauren in the Microsoft commercial, realize that they only have to spend on what they need. Who cares about the cool factor when they have to spend their money wisely? In early March, Microsoft CEO Steve Ballmer announced the company’s plans to deliver the “netbooks” of servers that sport features that meet minimal storage and network management needs of businesses.

By ExecutiveBrief

http://www.executivebrief.com

No responses yet

Apr 02 2009

The X, Y, and Z’s of Product Development

A certain thing happens in product development…  (It used to bug me to death, until I got used to it.)  Your product development team just finishes a great new feature.  Everybody rejoices.  Good feelings, pride, and celebrations.  All that…  The new release is posted on the web, and you start to get downloaders.  Potential customers are giving it a look.  And you know they are seeing the great new feature you just added.  It has “X” and “Y” new things.  Everyone will love it.  Everyone will buy.  You’re sure of that!  Finally… we’ve gotten a great product out there…

The next thing you know, you get an email from an evaluator.  He can’t believe how short-sighted your product is.  In fact, he’s practically indignant.  It’s missing a key feature he needs, and he can’t belive you’d ever consider shipping a product without it.

He asks, “Can you do it?  When will it be available?

“Maybe, next month.  Can you describe it more fully?”

“Oh, I can’t wait that long…  Forget it.”

The situation is that you’ve completed “X” and “Y” but haven’t gotten to “Z” yet.  And that’s what spoiler-boy wants.  Problem is, you never considered “Z” until you completed “X” and “Y.”  Or worse yet, didn’t consider it until he pointed it out.

This is so common.  People cannot see to very down the product road-map.  That’s human nature.  They can see “X” and “Y” but only have fuzzy glimpses of “Z.”  That is, until some grumpy customer complains that it’s not in the product.  He doesn’t see the hard work you put into getting the first releases out.  I.e. getting “X” and “Y” out.  He just sees that “Z” is missing, and feels pretty certain that he can’t do without it.  He’ll move on…  Somebody out there must have it.  “I’ll look around…” he says.

Better get cracking.  Again…

 

–ray

No responses yet

Mar 19 2009

Let the Client Be Your Project Leader

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:

  • Cooperation between client and vendor through a structured process. There has to be a mutual understanding of every step of the process and what is required from either party. Such expectations are written down as requirements, roles and responsibilities, decision points, milestones, and metrics.
  • The customer drives the project through customer-driven teams. The customer’s satisfaction is the end-goal of all efforts, and this satisfaction is defined by continuous quality improvement of products and services.
  • A link among the customer, process owners, and suppliers. The link refers to the integration of all efforts and internal processes used to arrive at task completion and their integration. Furthermore, this link also means unlimited access to clients, sponsors, and their project counterparts through open communication to set expectations and facilitate feedback.
  • A customer-led team that is fully capable to accomplish and improve every aspect of the project. The client is involved in building and managing the project team. But while the client has a high level of involvement in managing the team, members are encouraged to identify key areas of improvement, and communicate this knowledge. Unless empowered to do so through open communication, access to the right tools and technologies and trainings, project team members will only focus on accomplishing their tasks without so much regard for improvements in products and services, and this does not spell a healthy competitive spirit in the grander scale of things. In other words, make consultants out of project teams because in the long run, their accountability for the project will result in competitive products.  Encourage creativity and innovation.
  • A disciplined project management methodology. Clients and providers should agree on a project management system and implement this agreement at every stage of the product lifecycle. Because of the nature of this approach, the project starts and ends with quality, which means that quality issues are identified at the start of the project and addressed throughout its course. How quality issues are addressed also largely depends on a well-designed systems and implementation plans.
  • 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

    No responses yet

    Feb 17 2009

    The Key Success Factors in IT Business Alignment

    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

    No responses yet

    Jan 12 2009

    Building a Project’s Business Case

    Forward-looking project managers realize that to avoid failure, they should build the business case for their projects by getting intimately knowledgeable about the reasons why sponsors approved their projects.

    Too many projects get the axe because of the lack of business cases that justify their existence. When project sponsors begin to see projects only in terms of costs instead of potential rewards, there are higher chances that the projects would be canceled.

    It is not the job of the project manager to build the business case. Ideally, project stakeholders and sponsors evaluate the business value and possible ROI from a project. If the project is seen in terms of generating income or reducing cost, the project will have the green light. This is the situation in the ideal world, but this scenario happens a lot less than one would like to believe.

    Forward-looking project managers realize that to avoid failure, they should build the business case for their projects by getting intimately knowledgeable about the reasons why sponsors approved their projects. A project manager should work closely with clients, sponsors and other stakeholders, and ask the following questions:

    What problems should the project address?

    By interviewing project sponsors, the project manager can determine their goals and discuss the issues that the project would solve. In addition to project sponsors, the ones who are dealing with the issues at the workplace, perhaps on a daily basis, are a good source of ideas about the extent and many facets of the problem. Looking at day-to-day challenges from end-users’ point of view enables the project manager to get a better handle of the requirements of the project in terms of design and technical upgrades, as well as in terms of how it will solve end-user problems.

    What are the strategic goals of the project?

    Is it an easier system? Increased productivity? Better networking? Conversion to a marketable product? No matter what it the goals are, they must also come from and supported by the end-users.  At the end of the day, it will all boil down to the business value of the project. And by business value, it means cost reduction, better productivity, and the possibility of selling the product or service to the wider public.  Make sure that the goals are clear and the project’s objectives must reflect these goals.

    What are the project’s basic requirements and what can end-users live without?

    Aside from building the requirements based on the needs of its users, the project manager should also build the projects’ technical and design requirements and ask what bells and whistles it should have. The project may have a lot of feature that do not have business justifications, resulting in features that took too long to build.  Separating needs from fluff allows the project manager to formulate requirements, identify scope, and allocate resources that are important in creating a working version of the project. The quicker the iteration, the better the chances are of project survival.

    What is the project’s ROI?

    Even at the early stage of the project, it is possible to envision ballpark ROI figures. Because all projects incur costs, a project manager should have a fair idea of when investments will be recovered and generate positive cash flow.

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

    No responses yet

    Dec 18 2008

    What Agile Methods Mean to Your Process, People, and Products

    Studies show that most successful projects were those that followed agile principles, proving that model-driven methods are not always the best when it came to managing changes, fast-paced project implementation, or even meeting market demands.

    The concept of agile development is not new. However, many technologists still stick to the age-old notion that software development can be easily designed and the outputs predicted without giving much thought to the more dynamic factors of projects, such as communication lines, people, and change.

    Project managers eventually realized that a lot of projects failed because of rigid requirements, faulty design, and the inability of project teams to adapt to change. For the most part, clients or end-users’ requirements changed through the course of development lifecycles, that by the time applications were ready for deployment, the end products were a good degree different from what was initially planned. This would have been alright, except that towards the end of the development lifecycle, time and financial resources have overshot initial estimates by a good measure.

    Instead of pointing their fingers at development teams or clients, project managers learned to allow adjustments in their methodologies. In fact, many studies have shown that the most successful projects were those that followed agile principles, proving that model-driven methods are not always the best when it came to managing changes, fast-paced project implementation, or even meeting market demands.

    But before adopting agile practices, project sponsors and managers should ask how agile methods could impact their products, internal operations, and people.

    Impact on people and their roles

    A key agile principle, “individuals and interactions over processes and tools,” emphasizes communication and collaboration of project team members. Instead of defining the roles of team members, more importance is given to how well they can perform tasks as a team and create a working version of software. Teamwork cannot be overstated in agile processes, as each member can play the part of the end-user, leader, and engineer. To be truly successful, project managers should allow team members to wear cross-functional hats, communicate freely, and focus on team goals instead of individual—or role-based—functions.

    While it has been initially believed that agile method worked best with co-located teams, experiences of outsourcing service providers proved that this also worked—and perhaps better—with the offshore outsourcing development models. In the first place, collaboration and free-flowing communication is the norm, and not the physical set-up of the workplace.

    Impact on process

    Processes take secondary priority in agile methods. Instead of going through particular stages of the development lifecycle, rapid and short iterations move the project forward, allowing for flexibility in changing the course of the project. Moreover, instead of drowning in documentation as dictated by requirements and design, most documentation is in the form of information exchange among project members. Design and actual product are often inconsistent until the deployment stage.

    Impact on product and quality

    Instead of delivering software that has all the knots and bolts in place according to its original design, the highest priority is satisfying the need of the customer with a simple but working version. The adage, “in perpetual beta” also applies to agile method; software improves with every iteration until all the “nice to have” features are in place. Simplicity allows for more flexibility in change requests, especially because end-users and sponsors or clients eventually discover new requirements along the way.

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

    No responses yet

    Dec 08 2008

    Recession-Proof Your Business by Recession-Proofing IT

    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

    No responses yet

    Nov 18 2008

    Project Managers: People Don’t Like To Be Led

    Published by raywhite under Advice, Business, Project teams

    Project management advice: People don’t like to be led, especially professionals with clear responsibilities.  Nobody likes “a person who knows” to tell them what to do next.  All the time.  It’s demeaning and annoying.  So what’s a project manager to do?

    Clearly, project managers and leads need to stay a few steps ahead of team members.  If they don’t, projects go astray.  Why?  Because it takes time to formulate a clear vision, one that won’t break down in the face of life’s challenges.  Only by staying ahead of the team can the leadership maintain that strategic edge.  But it’s when that strategic direction turns into tactical dictatorship that things go badly.

    Some managers have such a hard time articulating their vision that they resort to dictating exact tactical steps to achieve it, rather than relying on competent people to pull it off.  See the issue?  It’s a difficult balance.

     

    –ray

    One response so far

    Nov 11 2008

    Beginning of the End: Defining Project Closure

    When undertaking a software development project, an effectively designed closure plan serves as an outline of required tasks that must be carried out appropriately in order to result in successful project delivery, and adequate preparation is one significant element when it comes to ensuring a smooth transition to implementation. The closure plan must be considered at the outset of the project, as the client outlines their specific software requirements. With a detailed description of the desired end result communicated and understood, the expected capabilities and deliverables of the software are established. But as you enter the final stages of a software development project, what can be done in order to ensure that the program is completely suitable and fully primed for implementation?

    Key Components
    According to Joe Coley, independent software developer and member of Northeast Dataflex Consortium, “Projects that I’ve been involved with…have been very much subject to additional needs and desires of the user community.” In effect, this means that the end deliverable becomes the focus of the closure plan — that is, to ensure a high level of end user satisfaction with the software requested and therefore created. Coley has 20 years of experience in the information technology industry and offers much insight on the subject. When it comes to key components for successful closure plans, he highlights three main aspects to consider:

    Assess the project requirements. In order to determine the best course of action throughout the cycle of a project, it is necessary to first consider the scope of the project. Establishing a clear outlook and complete understanding as to the required deliverables will greatly improve the ability to adequately determine exactly what tasks must be carried out in order to meet these deliverables in an efficient and timely manner.

    Communication. While communication is always essential throughout the cycle of any project or initiative, it is imperative to establish a specific plan for obtaining end-user input, as needed and where feasible. Therefore, a key component to a successful close is establishing and maintaining open lines of communication with the appropriate groups. The end users comprise the group of those who will be utilizing the software in real-time business applications; they have the critical business knowledge as to ways in which the software can be created or functionality that can be incorporated so that the result will be a valuable tool with the capability to enhance their business functions.

    Offer continuing support. When it comes to considering a focus on the continuing support needs of the end-user community, Coley cites a specific reason to do so, “There is always an expectation of continuing support in the form of application tweaks, bug fixes, and enhancements.” By extending continuing support to the end users, they have more confidence in the software program as well as in their chosen developer.

    Any components, however, are unique to each project and must be considered on a individual basis; while there may be similarities among projects, what may have worked well during a project in the past might not be best suited for a current project. Establishing and maintaining a plan with the end user in mind makes for a smoother transition and successful close of a software development project.

     

    Full text of the interview with Joe Coley is available here: http://www.executivebrief.com/article/the-beginning-of-the-end-defining-project-closure/.

    No responses yet

    Nov 03 2008

    Why is SaaS only popular in small business?

    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

    2 responses so far

    Oct 28 2008

    The Pros and Cons of SaaS

    Why SaaS may be the next wave in enterprise computing.

    Much has been said lately about Software as a Service (SaaS), which is often interchangeably referred to as “cloud computing”. While pundits may disagree on whether SaaS is cloud computing, its primary feature is application provided as a service to customers via the internet.  Because applications are hosted, this eliminates the need for installation and running of applications on clients’ computers, or even servers, as well as maintenance and support. Moreover, SaaS reduces the need to purchase and maintain hardware.

    But before getting into the much-praised or marketed trend, it is worth considering first why SaaS is such a hot commodity nowadays.  According to experts, security, maintenance, and cost are among the top reasons why SaaS is being embraced by enterprises.

    Moreover, due to the challenges that face companies regarding outsourcing, such as communication gaps and security, SaaS either supplements the need of businesses to outsource parts of their IT requirements. This is especially helpful for small and medium-size businesses that do not have large IT departments, or those that can only afford to pay general IT workers instead of specialists. Because staffing has become problematic due to reduced budgets that affect tech spending, SaaS offers a way to meet their technology requirements without spending more on overhead.

    Whereas the application service provider (ASP) business did not make as much mark as it should have in providing enterprise computing, SaaS is being touted as the trend that will replace and even overcome ASP.  Scaling was ASP’s main challenge, which required “separate execution environment” or different server environments for hosting different applications.  SaaS replaces multiple resources to run applications with shared computing resources, such as the same software version that runs on the same platform. This proves cheaper for end-clients.

    SaaS providers offer flexible contracts that have targeted costs for specific services. Many tech projects run for only a few months, so services that provide exactly what businesses need in terms of scope and time, with corresponding costs, are advantages that SaaS vendors are only too happy to explore.

    SaaS provide specialized software that increasingly meet clients’ needs. As vendors gain more knowledge about what businesses want, these insights are incorporated into version upgrades, which means better software and, just as important, more responsive service.

    It is common knowledge in any industry that freeing up the need to manage back-office processes, including technology services, allows companies to concentrate on bigger, more important business areas. Perhaps at the IT level itself, this is also true. Freeing up the upkeep of some technology processes allows IT departments to focus on the services that they can provide in-house.  In effect, SaaS vendors upgrade the quality of both hosted applications and, indirectly, the quality of services of in-house IT departments.

    By ExecutiveBrief
    www.executivebrief.com

    No responses yet

    Oct 21 2008

    9 Steps to a Hassle Free and Effective Software Development Project

    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.

    For any software development or other project initiative your company may be considering, it is critical to have in place and practice a set of effective and proven guidelines to ensure project success and delivery of the expected results: taking into consideration the role and responsibilities of a well-qualified project manager, knowledge of important business and financial aspects, and a step-by-step process that all contribute to the solid foundation and implementation of an effective project plan.

     

    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


    Step #2: Analyze and Determine Requirements
    Step #3: Consider Industry Best Practices
    Step #4: Design
    Step #5: Measuring and Tracking Progress
    Step #6: Development
    Step #7: Addressing Automation
    Step #8: Testing
    Step #9:  Gradual Implementation Practices

     

    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

     

    No responses yet

    Oct 14 2008

    Project Overload: Too Many Requests

    I once read a bizarre statement, written by an overloaded IT manager.  He was complaining about the heavy workload his executive management was throwing on him.  Here is what he said:

    When a new project request comes down, I just ignore it.  I ignore it until management makes it clear my job depends upon it.

    Wow!  That’s revealing!  Evidently, this poor soul is so swamped with exciting new projects that he is forced to ignore the bulk of them.  I can vividly see how these superfluous demands go down.

    First, the executives get a great idea.  Yeah!  Let’s restructure the customer database to maximize the communication [read: spam] we send out.  We’ll get some great sales!

    The project is handed off to Harold in IT.  “He’ll make it happen,” the suits say.

    Harold comes in Monday morning, sorts through 400 spams, and finds the outlandish request.  He rolls his eyes and drops it into the “Oh Boy!” folder.  And then he checks the ESPN stats.

    The execs never give the project another thought.  They just go off and reinvent the company ten more times, dumping an equal number of requests on poor Harold.  And he ignores them all.  He doesn’t have time for the fun.  He’s got real work to do.

    Am I off?  Got it all wrong?  Honestly, I don’t think so.  I’ve seen numerous projects like this get swept under the rug.  Execs don’t run the show, the little guy does…

     

    –ray

    No responses yet

    Oct 13 2008

    A Few Reasons Why Project Changes Occur

    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

     

     

     

    One response so far

    Oct 09 2008

    Down Economy: Billing Clients Imperative

    Published by raywhite under Advice, Business, Consulting

    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

    No responses yet

    Oct 06 2008

    The Key Elements to Managing Projects the Virtual Way

    It is not enough to manage projects virtually, but to properly apply e-project management processes that result in less development time but with improved quality. This is about value and not just cutting costs, after all.

    Advancements in telecommunication are among the key movers of offshore outsourcing. Without it, back-office operations and application development outsourcing will not be as successful as they are today.  Better infrastructure has allowed for richer applications and cheaper communication that enable businesses and their outsourcing partners to manage people and projects efficiently from different time zones.

    Adopting virtualization in managing project offers great competitive advantage to companies and offshore project teams. However, with the increasingly virtualized tech industry, it is not enough to manage projects virtually, but to properly apply e-project management processes that result in less development time but with improved quality. Remember that this is about value and not just cutting costs, after all.

    To make a successful adoption of virtualization, a few key elements are involved.

    Infrastructure – Both client and vendor must set up the infrastructure that can support virtualization efforts, particularly when the project at hand involves sensitive information.  Both parties need the hardware and software to host VoIP calls, and in many cases, virtual private networks (VPN).  At the start of the project, prioritize the acquisition of hardware, software, and bandwidth to support collaborative and communication efforts.

    Communication Plans – Much of the success of adopting virtualization in depends heavily on communication.  On-shore project members do not have the advantages of following up colleagues whenever they want or in person. Delivery teams, on the other hand, do not have the luxury of clarifying project details immediately. In this regard, it is best to set up communication plans that define identify proper channels and approaches. Are there available people on the other end of the communication line? When should the team use virtual meetings? Is e-mail enough to update one another about the project status? Who will project members ask about issues—specific persons or entire teams? Experts agree that it is better to err on the side of over-communication.

    Control and Evaluation – On top of delivering results at a time when they are expected to, offshore project teams should report plans for manpower allocations and utilization, risks and issues, and milestones.  By having these details, project teams—no matter where they are in the world—can evaluate project status and control risks. This also involves a single control system that allows for an easy generation and consolidation of data.  At the end of every period—typically weekly or monthly—such data can be measured to evaluate the success of the project in terms of quality of work, manpower and financial investment, and the lessons learned from the venture.

    Collaboration Tools – A repository accessible to every member of the delivery team should be put in place. Do not rely merely on multiple copies of outputs stored in individual folders. Versioning and project management software, such as SharePoint or Perforce, allow project team members to work on single source copies of outputs, as well as archiving, checking out and backtracking of works.

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

    2 responses so far

    Oct 02 2008

    Economic Downturn Means Project Upturn

    Published by warren under Advice, Business

    It is easy to become victims of the media’s scare tactics and dramatization. It is no longer good enough to simply report facts. The 24/7 news cycle has many news organizations using entertainment to fill air time. It is common knowledge that shock sells. So, we are now inundated with doom and gloom from the ever-present talking heads. Somewhere in between is the truth.

    This brings me to a point about projects and the slowing economy. Should we all just stand still and wait to see what happens? Or, like many companies, do we look at this as an opportunity to gain more market share?

    Projects evolve for many reasons, but even more common among them, is the understanding that projects will either create a revenue stream, or they will streamline costs which will in-turn add to the bottom line. Yet, for many businesses fear takes hold and many stand pat. If a project will save you money or make money, why stand still?

    During the dot-com bust and the days following September 11th similar economic fear gripped our nation. I remember working for a small company that decided to go bold or go home. If the business was going to fail it would do so despite vision and forward thinking. The company grew and was more profitable, while a few of our competitors fell, in part, because they froze.

    I believe in being prudent, but I do not believe in giving into fear. If a project makes sense, go for it.  If not, make sure it is not because of fear.

     –Warren

    No responses yet

    Sep 22 2008

    Bad Decisions Ruin Credibility

    Published by warren under Advice, Project teams

    It is not easy being perfect, just ask Ed Hochuli, a widely respected NFL referee who blew a huge call last week during the Denver Broncos’ San Diego Chargers football game. You can not miss this guy. He has been a referee for many years and has worked playoffs and Super-bowls. Not to mention his arms are the size of tree trunks and he looks like he should be playing line-backer instead of throwing flags.

    Anyhow, the point I am trying to make is that this guy set the standard for NFL ref’s throughout the league. Week after week, game after game, Ed Hochuli was the definition of steady and consistent.  In the world of referees, he was considered the best. Then came last Sunday, one bad call and bam!  Many in the media and fans across the country deriding him as brainless and calling him the worst referee on the planet. 

    However, Ed is taking it like a champ. He is facing up to his giants. After receiving hundreds of hate filled e-mails, Ed is personally responding to every single one with a sincere apology.

    So, what is the lesson in Project Management? You have got to be on your game and make the right decisions without EVER making a mistake? That’s impossible! But, what we can control is how we respond. People respect someone who takes responsibility for their mistakes. So, own up to it and move on. Only then can your team do the same. 

     

    –Warren

    No responses yet

    Sep 15 2008

    Words Have Meaning…Coach.

    I have written in past blogs about Project Management being a lot like coaching. One part of this I want to elaborate on is our words. I can imagine, in the heat of battle, coach Paul “Bear” Bryant would drop a few “f” bombs on a player, get in his face, and challenge him to do more–and to do it better.  That does not fly as well in the corporate world. A football player can rush on the field and translate that aggression into physical action. It works on the field but not so much in a cubicle.

    However, in the office, a manager must still learn to pull the right strings and push the right buttons. The best way to do this is by getting to know your team. Use personality profiles, spend time with your employees sharing their interests, and things outside of work. Then, you will have a better feel for who needs a kick in the pants and who needs a pat on the back. NOW GET YOUR TAIL OUT THERE AND MAKE SOMETHING HAPPEN…and do not drop the ball. 

     

     

     

     

     

     

    –Warren

    No responses yet

    Sep 02 2008

    PM aide during the day - the power nap :)

    Hello,

    I’m a project manager for Hewlett-Packard and enjoy my profession.  A power nap doesn’t apply to all, as there’s some people who can’t get to sleep for awhile … maybe to tense or tight … then there are some of us … who work from home … didn’t sleep so well the night prior and sometime during the day are tapped … so I recommend - “The Power Nap” … which for me these days is about 10 - 15 minutes and then I’m good for another 2 hours at least … one can set the alarm on your cell phone {make sure it’s on the standard setting, not vibrate} and enjoy … I find I’m totally refreshed and can really be productive on the next challenge, as opposed to trying to push my way through and aren’t as effective as a moment will provide … and for those working in an office … I guess there’s always the jaunt out to the car for that quiet moment …

    I used to drink coffee to muscle through those moments but 15 - 20 cups a day makes me jittery by the end of the day.  :)

    Hope this helps and … may your journey as a PM be an enjoyable one.

    God bless.

    Cheers,

    Bill

    No responses yet

    Aug 29 2008

    DCAA Compliant Projects

    Published by warren under Advice

    Are your projects DCAA (Defence Contract Audit Agency) compliant? Maybe you have never heard of this term or perhaps you have never worked with a government contract. In any case, for many people it is highly likely that some day you will. 

    Becoming DCAA compliant can be a daunting task. It requires some very general rules on some items and is very specific in most areas. There are guidelines on how to submit proposals, how to track work on those proposals, and it even mandates internal procedures to comply with the DCAA’s rules and regulations. It is so steeped in red tape that there are nearly 100 classes offered on DCAA compliance training. I would not dare bore you with all of the details here, but it is worth noting that consultants/accountants are available who specialize in this field. However, be warned, they are not cheap. 

    In addition, there are time keeping/project management tools available like Standard Time that support project efforts to become DCAA compliant. There is a sizable market in government contracting and a nice cottage industry for consultants that specialize in government contracts.  The moral of this blog is take advantage of the expertise available to avoid having to sit through 70-80 classes on DCAA compliance.

    –Warren

    No responses yet

    Aug 22 2008

    Overdraft Protection For Project Management

    Published by warren under Advice, project management

    Many banks offer overdraft protection for their customer’s checking accounts. It could be for an attached savings account, a small line of credit, or another mechanism designed to cover any over-runs on your checking account. After all, mistakes happen. This is a little insurance policy you may never use, but it is better than paying large overdraft fees.

    So, why on earth are we talking about this in a project management blog?

    Well, it is simple. Do you have any protection against project budget over-runs?  Any last line of defense?

    A main part of a Project Managers’ job is to successfully finish a project on time and under budget. With all of the variables involved, that is a tough proposition! For help with cost over-runs you may consider a tool like Standard Time®. Standard Time contains an automated feature that sends warning e-mails when a task or project is nearing the intended limit. In addition to the warnings, a Project Manager can set a “no pass” limit that will prevent an overrun or an allowance, but only if the Project Manager/Administrator allows it.

    Task Warnings in Standard Time®

    Nothing is fail safe. However, Standard Time is one tool that identifies impending problems and may be the extra nuance that keeps your projects on track.

    –Warren

    No responses yet

    Aug 20 2008

    Advice: Develop Products for the 98%

    Published by raywhite under Advice, Product development

    Here’s some project management advice: And I’m going to complain a bit…  Hope you don’t mind.  :)  I notice user interface design - especially in software products.  I notice menu placements, dialog box layout, screen widgets, and everything else.  And there’s one thing that always bothers me.

        Complex products seemingly designed for 2% of the intended users - %*^$*#

    Developers fall into a common trap: adding too many menus and screen gadgets.  Here’s how it happens…  Sales managers, product managers, and CEO’s all want products to do something new.  Something big and flashy.  Something they can sell.  So, they call down to the developer’s cubes to make it happen.  And it does!  Unfortunately, so do dozens of other feature requests.

    Developers often don’t know how to bury the obscure features and highlight the common stuff.  Everything is given equal weighting in the user interface.  That’s okay until you have a hundred big features.  And then everything runs together.  Users see so much stuff, they can no longer gear the product to their own purposes.  It takes a Masters degree to figure it all out.

    A better approach is to develop the product for the 98% of customers who will use it.  In other words, MAKE IT SIMPLE!  Bury the features intended for the other 2%.  That doesn’t mean you’ll only bury 2% of the menus and dialogs because normally about 50% of the product falls into the “obscure” category.  Bury all that, and explain it to the 2% who need it.

     

    –ray

    No responses yet

    Aug 06 2008

    Advice: Create Layered Products

    Published by newshirt under Advice

    Project management advice: Create layered products that allow you to release new updates once a month.

     

    I was originally planning to title this post ‘Create foundational products’ and then I quickly realized that the foundation is only the first layer of this strategy.  I’m advocating short, quick releases, in layers.

    I’ve found that big, monolithic product releases have several downsides.  They are often riddled with bugs and usability issues, and sometimes require several slipstream releases to resolve all the bad stuff.  Developers bite off more than they can chew, and the product becomes so complex that complete testing is not possible.

    Small, frequent releases solve this problem.  With each release, you have the opportunity to fix prior bugs and advance the grand design a little further.  True, you can’t toss out your ‘take over the world’ design in one giant release, but given some patience, you’ll get there.  And the product will be a lot more solid when you finally reach that point.

    Start with a simple foundation.  It probably won’t have all the features customers are screaming for, but it gets you started.  Follow up with several small releases that fill in the gap.  Listen to beta users and customers, and build the grand design with their input.  Trust me, you’ll be a lot better off in the end.

     

    –newshirt

    No responses yet

    Jul 31 2008

    Advice: Track Project Time

    Published by raywhite under Advice

    Project management advice: Track your project time.

    Organizations perform projects for a lot of reasons.  Consulting companies perform the same projects (often with small changes) for every customer.  Manufacturing and engineering companies build things, requiring complex engineering projects.  Government organizations perform IT and data processing projects.  Every one of these can benefit from tracking project time.

    Whether you use a timesheet or computer-based timer, tracking your time provides several advantages.  Some managers have no real idea how long their projects take.  They have a gut-feeling, but no hard numbers.  And trusting your gut only works when steeped in actual numbers from the field.

    No more guessing
    WIth actual numbers behind you, there’s no need to guess.  You have the hard facts, and they cannot be disputed.

    Accurate finish dates
    Assuming you have have performed a similar project in the past, setting a finish date will be a no-brainer.  You’ll have details to back up your outrageously long schedules.

    Concise records
    This is crucial for consulting companies.  Client billing depends on accurate numbers to back up your invoices.  But manufacturing and engineering groups also need good records to back up their project cycles.  In the end, clients and managers want to know what you have been up to.

     

    –ray

    No responses yet

    Jul 28 2008

    Advice: Have a Project Champion

    Project management advice: Every project needs a champion.

    It took me a while to understand the nature of product development and the need for project champions.  At the beginning of my career, I believed projects just “got developed.”  I was working in a research department at Eastman Kodak Company, building cutting edge photocopiers.  Engineers buzzed around, building microprocessor-based circuits, image-enhancing emulsion, and writing software.  I did my part and just expected the product to come together.  Looking back, I now realize there was one man who made it all happen: a gray-bearded old dude who wanted to change the industry.

    Products get developed, and projects finished, only when there is someone with the burning desire to see it happen - like the old bearded dude in the example above.  A paycheck is not enough.  You have to want it badly.  Only then will you fight through all the obstacles to make it happen.  Projects often take 2-3 times their original estimates, and some required several iterations to realize the full glory.  And only a true champion will endure the suffering to see it to completion.

    Look around at your project.  Do you have a champion?  A person who refuses to give up?  If not, you have good reason to fear that the project could be canceled or back-burnered.  Have you personally ever been a project champion?  If not, give it a try.  Throw yourself into something that really engages your passions.  You’ll find there’s satisfaction in a job well done.

     

    –newshirt

    No responses yet

    Jul 21 2008

    Advice: Get Corporate Buy-in

    Published by raywhite under Advice, Project failure

    Project Management Advice: Get Corporate buy-in for your projects.

    In other words, make sure the corporate executives are active stakeholders in your project.  I suppose this goes without saying, but I’ve seen lots of projects where this is not the case.  Project teams somehow come to the conclusion that their project will be funded and accepted, even though corporate has not explicitly said so.

    Just because your team is developing a new product or in-house tool, doesn’t mean corporate will stand by you.  Without vested stakeholders at the highest level, your project could easily be canceled.

    The name “Harold” comes to mind when thinking of this subject.  I worked with a man named Harold who was researchinig a product for his company.  Months went by as he studied the features and benefits.  He eventually took a job with another company and I discussed the project with his boss.  His boss said he never knew what Harold was up to, and had no intention of adopting the product!

     

    –ray

    No responses yet