Archive for category Project-Based Solutions

Here are the Top 5 Reasons why Timesheet.com is a Solid Time Tracking Solution

Written by : Tanya Grant – Project Manager PMP, Upland Software

After some extensive research, we have identified the top five time & billing issues faced by companies today, and propose how Timesheet.com can help address them.

1.   Inaccurate billings/billing errors: Errors of any kind can be bothersome and frustrating. Errors in billing however cut into a firm’s profitability, ultimately hurting the company and its accounting department. Timesheet.com’s Billing & Invoicing module has been designed to automate your entire time and billing and revenue reporting process. With certified connections to your CRM and accounting system, an opportunity in CRM becomes a project in Timesheet.com where it is planned, budgeted, tracked and billed. Detailed or summary project cost and billing information is then posted to your financial system’s accounts receivable, accounts payable and general ledger modules, ultimately eliminating billing issues by streamlining the billing process, making it easier to track, plan, budget and bill.

2.   Timesheets not entered: Incorporating a systematic time tracking system can be a little overwhelming. Timesheet.com eliminates unnecessary time entry and/or errors with its simple and easy-to-configure interface. Users quickly adapt, improving collaboration and strengthening employee organization.

3.   Missed milestones: Missed milestones can occur when costs and budgets aren’t being properly monitored. Setting up dashboards and extensive reports is easy with Timesheet.com, improving analysis and financial visibility – so you never have to worry about financial mistakes again.

4.   Incompatibilities: Choosing a time and billing system and then discovering it does not integrate with your existing applications can be discouraging. Timesheet.com has built-in and certified connectors to all leading financial, ERP, HR, payroll and CRM applications. The connections are built-in. No custom programming is required for standard integration. Data can be exported to and exchanged with leading systems for accounting (Great Plains, Navision, Solomon, Sage MAS, Accpac, Peachtree, Pro (SBT), SAP Business One, Epicor, QuickBooks, Intacct), payroll (ADP, Ceridian, Paychex), ERP (SAP, Oracle, PeopleSoft), project planning (Microsoft Project), CRM (Salesforce.com and Microsoft CRM), HR (Taleo), and much more. In other words, there is no need to “rip-and-replace” your existing applications.

5.  Capturing timesheets in multiple disconnected systems:

- Some departments track time for payroll processing: IT and product development teams use their own project tracking system and may capture project time and expenses; the professional services team uses spreadsheets or a silo-ed time and billing application. It takes considerable spreadsheet gymnastics, manual adjustments and merging to compile data from these disparate systems into operational time, cost and revenue reports.

Using spreadsheets or multiple disparate tools to track time leads to inefficiencies, and poor project cost/revenue visibility. Your management team does not have access to real-time report on projects and operations to measure progress and make informed decisions.

- Out-dated or in-house developed time tracking software: Legacy-outdated time tracking systems have high maintenance costs, ongoing fix and enhancement tasks; divert precious internal resources and attention away from the organization’s core business.

- Lack of effective internal controls for time sheet management: Weak internal controls for time sheet and expense reporting lead to violations of company work policy, inaccurate cost accounting or violation of employment laws; your business may face severe penalties and lose investor confidence when such weaknesses are discovered.

Are you having any issues with your other time tracking processes that aren’t on our top 5 list? Please feel free to let us know.  We would love to hear your feedback, questions or concerns about the above

No Comments

An All Purpose Checklist for Project Closure

This post is from Kevin Sequeira, Product Manager for Tenrox, the leading workflow-driven  project
management and professional services automation solution.
 

You’ve reached that point in the project where you stand at deployment and you are ready to shake hands with the project customer and move on to your next assignment.  Do you just flip the switch, wave goodbye and ride off into the sunset?  Is your job complete?  How do you know…what is your yardstick for saying, “that’s it, we’re done here!”?

From my project experience there are some key steps and critical things to check on as the project is deploying so as to ensure that the engagement is over and the solution is ready for the project customer.  I’d like I present what I consider to be a reasonable ‘general’ checklist for use at project close out to ensure you’ve dotted the ‘I’s and crossed the ‘T’s before moving on to your next project.
 
Are all deliverables delivered?
Review the project schedule closely. Has your project team successfully delivered on all project deliverables?  And just as importantly, do you have something documenting customer acceptance of each project deliverable?  Is there a formal signoff in your project folder?
 
Are all invoices current?
Most projects either bill time and materials, by deliverable, or monthly. Look through all project invoices. Has everything that should be paid up till now actually paid?  If not, now is the time to check with the customer to see if there are any outstanding invoice issues and work to resolve them quickly.
 
Has a lessons learned session been conducted or at least scheduled?
I’m a fan of conducting one or more lessons learned sessions before the actual point of deployment because it’s hard to pull everyone together after the solution has been turned over to the customer and to support staff. But if you’ve not held a session yet, schedule that now with the client even if it’s just a one or two hour phone call.
 
Have all user acceptance testing (UAT) issues been resolved?
How did UAT go?  Were there any remaining issues to be fixed?  Ensure that those have been acceptably resolved prior to deployment. Make sure that you have a formal UAT signoff in hand as well – a project that does not have a formal testing acceptance from the project client should not be headed for deployment.
 
Are all training issues completed?
Most customer solutions require some level of training to be conducted for the customer’s end user community.  Naturally, this would have been well laid out in the project schedule with specific tasks designed to ensure that this is accomplished.  Review the schedule to ensure that all training tasks are complete – a customer who doesn’t know how to use their newly deployed system will likely not be a satisfied customer who gives good references to other potential project clients.
 
Is a formal project acceptance signoff ready for the customer?
Finally, do you have a formal signoff document ready for the customer to sign upon deployment of the final solution?  It’s important that you’ve been accumulating ‘official’ acceptance signoffs on all deliverables up to this point, but this one is probably the most important of all as it signifies overall acceptance of the deployed solution to the customer.  Any discussion of remaining outstanding invoices will likely begin and end with this signoff, so make sure that it is always part of your project closure
checklist.
 
Summary
This is my practical checklist for closing out a project engagement.  Readers – do you have other things that you would suggest adding to this list?  What other items do you consider critical to every project to cover before considering the engagement closed out?

No Comments

5 Key Challenges for Project Managers in Services Organizations

This post is from guest contributor Brad Egeland, a leading project management consultant and author. His website, bradegeland.com, is regularly lauded as a top blog for project management, PMO and Agile related topics.

Project management in any environment can be a challenge – there is no doubt about that. But when you’re involved in a professional services organization and working with shared resources and delivering on projects with tight budgets and tight schedule commitments – not to mention likely juggling four, five or even six or more projects at a time – it can get become a very daunting task.

While the list of challenges for project managers is definitely never ending, I’ve created my own ‘Top 5’ list that I’ve encountered over the years of managing projects. They are listed in no particular order of importance, but all can be devastating to your project if not managed well and responded to proactively and appropriately.

Read the rest of this entry »

No Comments

Sales to Service and Everything in Between

Written by: Marlon Arevian – Senior Solution Consultant, Tenrox

Ahhh…the life of a Solution Consultant! They sit warm and snug, in between the Sales and Service departments. Solution Consultants’ inherit a hybrid role of ambassadors for their company’s products during the pre-sales process while effectively assessing scope and mitigating risk for the Service Delivery Team. They also bridge the gap of the high flying energy and emotional rollercoaster of Sales to the pragmatism and well-drawn lines of Professional Services. Outside of showcasing product offerings to potential customers, a big part of their job is to communicate what exactly our new customers are looking to accomplish. The Services Team needs to know things like objectives, scope and risks which were collected during the pre-sale process. Solution Consultants own the post sales knowledge transfer process which saves our customers a ton of frustration from not having to repeat themselves and allows our professional services team to kick off a project on solid ground. It also ensures that the customer vendor relationship is fluid from their initial contact to being live on the system.

Read the rest of this entry »

No Comments

The 2009 Chaos Report – Is Project Success Really that Rare?

The Standish Group released its widely quoted report (available for purchase here) on project success in April 2009. The latest report is based on a survey of more than 300 organizations and 30 interviews. A summary of the findings is shown in the figure below.

SuccessRateGraph

The news is not very positive. According to this report the number of IT projects that failed has actually increased since 2006, successful projects are also alarmingly harder to find. Here is a far smaller and less official survey on software project success rates.

From our own experience and all the anecdotal evidence I have gathered projects are often late and over budget but they are mostly successful. In my opinion the Standish Group’s survey is overly pessimistic on the success rate of IT projects. I find nothing on the Internet that explains Standish Group’s survey approach or confirms these findings. It would be better if they provided more details as to how they assess project success and how they can backup their claim of a negative trend in worldwide IT project performance.

The report did not highlight any new reasons for the higher project failure rates. There are many more capable and highly qualified project managers today than in 2006, there are better tools, an abundance of easily accessible information on project management lifecycles and methodologies, and better collaboration between all project contributors/stakeholders. I simply cannot see how the end results can be this bad.

2 Comments

Applying Occam’s Razor Principle to Product Design – Lessons learned from our Project Management Software design experiences

Occam’s Razor principle by a 14th century English philosopher states that “plurality should not be posited without necessity” or “when there are multiple approaches to solving a problem just use the simplest approach”. Seems like such an obvious statement but so much of the products we build and use today totally ignore this principle. The following best practices are based on the mistakes we made and lessons learned in building a project management software application.

Applying Occam’s rule to product design and development could go something like this:

  1. Design features that are simple to use
  2. Provide just one way of performing a function
  3. Don’t oversimplify

1) Design features that are simple to use

If you can implement a feature using several design options choose the simpler one. However, for most product development teams choosing the simpler design is easier said than done.
Here’s why:

  • There is a tendency to try and build an all in one comprehensive solution

    Since a variety of internal and external stakeholders participate in the analysis phase, designers often keep adding complexity to satisfy the many parties and differing agendas involved. Therefore, often a product that was intended to automate a simple function or provide a simple service turns into a complicated device that can “do it all”, right out of a science fiction movie. 

  • Developers are naturally biased towards paying much more attention to handling extreme cases and boundary conditions at the expense of basic patterns of usage

    I have seen the negative impact of this firsthand at Tenrox. The complexity of software developed is increased by a factor of ten when developers try to cover all possible scenarios. Let me provide an example, a few years ago our R&D team redesigned Tenrox Project Workforce Management’s rate engine so that it could support a variety of cost and billing scenarios. When the new software was released, to our surprise, a few large customers with simple cost and billing rules reported significant performance issues with the new rate engine. After some analysis we discovered that these customers were using standard hourly rates, and yet the rate engine’s new design, which had absolutely nothing to do with hourly rates had been overcomplicated and slowed down a simple calculation that was working just fine before. Of course, the engineers went into emergency mode and had to come up with short and long term fixes to their overly engineered design. It takes considerable senior executive attention to reduce this bias and it is an ongoing battle in our product management and R&D teams.

  • Iterative reviews focused on what is missing complicate product design

    After working with our R&D team on several product releases over a fifteen year period we have identified this as a recurring pattern to avoid. Here is an example. We met about a year ago to redesign our software’s budgeting feature. The designers had come up with what they thought was a simple elegant solution that they claimed would address 95% of the requirements we had encountered. The meeting started on a positive note and everyone participated in the design review. A few people made suggestions of small things they thought were missing. Eventually there were many more ideas, new, even some commonly observed, usage patterns the designers had not considered. Within minutes the simple design was thrown out the window, and a complex multi headed beast of a budgeting feature design reared its ugly head. We all walked away from the meeting a little more tired, uncomfortable with the outcome. R&D ran with the feedback and put a few good developers to the development task. Six weeks later we were invited to another meeting to get a more in-depth view of the design, including some design mockups. The meeting was a disaster; the feature had become so complicated that virtually everyone agreed that the entire design should be killed. After wasting six weeks of development time, the designers went back to the drawing board and re-designed the feature from scratch. The second revision had fewer features than the initial design they proposed! But it was just the right combination of automation and ease of use. Our third design review meeting was an overwhelming success and the new budgeting interface was a hit.

2) Provide just one way of performing a function

As any product evolves, especially of the software type, we keep on adding more and more new functions. For example, in a version one, you can only create a project from the setup page. But based on customer feedback, by version 5, you can create a project while on a dashboard page, from the project manager summary page, from the customer page, while creating a portfolio… However, if you look at the products that are often viewed as amazingly simple yet effective designs such as the iPod or Google ‘s user interface the user is given very few choices of performing the same function. I had our R&D team hang pictures of the classic iPod with just five buttons in all their meeting rooms so they are constantly reminded of the importance of this bare bones “get it done” philosophy.

3) Don’t oversimplify

This is perhaps the hardest rule of all. Let me explain with an example. Developing a timesheet application seems pretty straightforward these days and is considered by most to be a simple application to buy or develop. That is until you get into the details of the varying department specific time tracking user interface and timesheet policy enforcement requirements, cost allocation, billing, leave time and overtime calculations, and approval processes that have to be accounted for and automated. Not to mention the complexities of integrating a timesheet with payroll, accounting, project management software, and CRM applications.  We are often faced with prospects who try to oversimplify such requirements, choose an under-powered product or do not make the proper investments, and pay a very heavy price when these issues resurface in the tail end of the implementation.

However, even if your product can and must handle complex functions, always focus on the most common use of a function. If you need to implement complex or boundary scenarios they can not impact the average use of the function.

In a future blog, I will apply Occam’s Razor principle to making IT investments.

1 Comment

Project-Based Solutions: Recommendations for Project Workforce Managers

Forrester Research Analysts R “Ray” Wang and Andy Salunga have published a new report entitled "Trends 2008: Project-Based Solutions" which is highly relevant to project workforce managers and the executives who run project-based organizations. Project-Based Solutions (PBS) is Forrester’s term for the array of software products, including Project Workforce Management, that enable companies to deliver services and projects. The full report is available here.

Here are my key take-aways for project workforce managers who seek a solution:

  • "Traditional approaches segmented by internal or
    external stakeholder orientation and product or service delivery no longer make
    sense," states Wang. Companies that have a good solution for serving either internal or external customers are doing their best to leverage their project-based systems to the other type of customer and project. Companies who are looking for a solution should consider the solution’s ability to help deliver both internal and external projects.
  • "Metrics have also emerged as a critical focus for project-based solutions. Companies continue to need performance measurement tools to help them understand how well they are executing projects and programs relative to plan." This means that companies are relying more heavily on these solutions for actionable, real-time information—not just weekly or monthly updates.
  • Wang recommends: "Align your requirements with project-based processes. In fact, some of the vendors we interviewed indicated the opportunities for smaller organizations (200-1,000 employees), particularly in the services delivery automation space, to quickly standardize their project management methodologies." Implementing a project workforce management solution gives a company a rare and critical opportunity to standardize product methodologies and many other business processes using templates and workflows.
  • Integration to, or inclusion of, other enterprise processes is critical. Wang mentions specifically "core financials, core human capital management, or other project-related systems." Companies rely more heavily on their ability to share and use the information they gather with project-based systems, but also need to prioritize IT spending for custom integrations more carefully.

No Comments

Project Prioritization and Selection: “Juggling School” for Project Workforce Managers

What if the attention and resources required by one project–the "squeaky wheel," as they say–starve another project that happens to be more critical? This happens all the time in companies that lack the right processes. Strategic projects can easily take a back seat to "pet" projects, or work that happens to be more crisis-driven.

I was recently interviewed for an article that has been published on NewsBlaze.com: "’Juggling School’ for Project Managers: Seven Reasons to Overhaul your Project Management System." This article focuses on project prioritization and selection. (There is also a chapter in the book, Rise of the Project Workforce, that goes into detail on this topic.)

In the article, I described seven major advantages to prioritizing and selecting projects using a five-step process that is described in the book. Below is a condensed version of these seven reasons for implementing processes around project prioritization and selection. Click here to read the article in its entirety.

  1. It allows you to organize your company’s best interests. Like an iTunes playlist for your projects, the project portfolio puts access to the most valuable projects in one place. Managers can compare projects, make funding decisions, and report on and analyze a collection of projects in one entity.
  2. It takes the guesswork out of project management. Implementing project prioritization and selection processes elevates decision-making to a more strategic viewpoint by aligning and assigning projects with business priorities. It also helps optimize resource allocation.
  3. It provides guidance for new projects. It helps you add new projects to your queue without misallocating resources to them. At the same time, it helps you allocate enough time and manpower to ensure quality results.
  4. Risks are assessed from a global perspective on their overall impact. New risks can be assessed more thoroughly and with respect to how they will affect the company as a whole. The steps you’ll use to organize your project portfolio will help you weed out those projects that contain too much risk to pursue.
  5. It helps you know when you have the resources and when you don’t. The system allows you to balance your resources.  Your ranking system will help you see when resources need to be reallocated, and the weighting and ranking is there for everyone to see.
  6. It is less time-consuming than juggling projects. The great thing about this system is that it doesn’t need to be constantly poked and prodded. In fact, it is important not to upset the portfolio too frequently by constant prioritization and resource balancing. We recommend you have a minor review each month and a major portfolio review once every quarter.
  7. It makes people more accountable. If a project doesn’t receive the funding or manpower it needs to be successful or if it fails for some other reason, leaders will know what went wrong where, and can address those issues with the appropriate employees. But more importantly, be sure to establish a framework for continued process improvement so that lessons learned and metrics obtained may be used to improve future project selection, estimation, and ranking decisions.

Today’s businesses–especially enterprises that manage hundreds of projects–can no longer afford to prioritize and select projects in a haphazard manner, or by allowing "pet" projects to carry the day. A company without these processes is destined to stray from its strategic vision, and lose its ability to compete.

You do not have to invest in a large new software suite to accomplish the above. There are simple tools out there that can help you automate this process; even using a few in-house developed spreadsheets and manual project value data collection is better than status quo.

1 Comment

PPM Needs the Project-Centric Approach

We received interesting comments from Philip McGuin of Atlantic Global in response to our recent series from David Hofferberth about the Project-Centric Approach.

We enjoy the debate. McGuin says Project Portfolio Management (PPM) empowers the business, but he assumes that project-centric approach is old news. Hofferberth says that taking a project-centric approach is a key stepping stone to successful PPM, and that it has not been adopted as much as we may think.

PPM and a project-centric view of the business go hand–in-hand. Unless a project centric approach is adopted, standardized and perfected, then projects will most likely fail—we have all seen the research and statistics on the percentage of projects that fail or go over budget. Granted, some projects fail because they might not have been the right projects in the first place, but more often than not, execution and management of resources are the problems.

If standardizing project management techniques and methodology is unsuccessful, then moving up to the next level of managing portfolios of projects could mean that organizations are getting ahead of themselves, and not getting to the root of the problem.

There are several associations and communities in the project management arena that continue to educate and introduce new methodologies, standards, and best practices. These groups continue to grow. Clearly, a lot of people are still working hard to perfect project management—and therefore the project-centric approach. And they must reach a certain level of maturity in the adoption of a project-centric approach before they can even entertain PPM.

PPM is a great goal for the more mature project-centric organizations, where empowerment is at the level of the business (top-down), but the first step in empowering the “top” is making sure the right approach is adopted at the bottom— in the trenches, at the foundation. Empowering the project-driven workforce with the tools, methods and best practices is paramount for executing projects successfully and for providing the “top” with the information needed to make better decisions faster.

No Comments

The Project-Centric Approach, Part 4

Projects Help Everybody to Think Strategically
by R. David Hofferberth, Service Performance Insight

In the previous parts of this series, I’ve explained how businesses who think in terms of projects have better information from which to make strategic decisions. The strategic aspect of the project-centric approach doesn’t only help management make the big decisions—it also helps workers at all levels understand priorities and efficiencies better.

Too often project prioritization and funding is done in a vacuum, with very little apparent “rhyme or reason” as to why specific projects get funded, while other, perhaps seemingly more important work, is not. The project-centric approach shows everyone in the organization the relative threshold for project consideration, and therefore individuals with perceived project needs can efficiently analyze potential work to see if it could be deemed as fundable.

This approach to business will obviously compel people to carefully consider their own work. People who work on projects are more likely to think of their work as a series of investments (of their time and effort) and returns on those investments for the company—as opposed to a stream of activity with undetermined value. As project workers, they can better understand how to minimize variances, correctly state costs and benefits, and reduce risks to themselves, the work of their teammates, and the business as a whole.

No Comments