Whenever our team has attended a Connectwise event, we are often looked at as if we are strange alien creatures because our firm actually uses the workflow rules.  The workflow rules within the application are a little clunky, but their power is the factor that will take your service team to the next level.  We have found that by automating certain processes, the return is not only found in saving time, but creating processes because we know what the expected outcome will be each time an event happens.  Let me walk you through an item I love and one that I find very limiting.

I will assume you all have figured out SLAs and Agreements and how all of those play into the execution of workflow rules.  If you have not and I get enough feedback- I will be happy to discuss this in another blog.

LOVE It:

• Change Board Action- Whenever a criteria is met, the action is set for the board to change.  We use this rule for a couple of very important reasons.  We have a Service board that is monitored for incoming issues.  If one of our support team members needs to escalate, we have them set the ticket to a certain status.  After the ticket is in that status for 5 minutes, the action is set in the rule for the ticket to move back to our incoming issues board.  With good notes in the ticket, our team can now assign an escalation person or assign the ticket to another resource.   This is one of the best action items Connectwise has built.  **Be careful- the ticket takes the default status of the board it hops to.

NEED It:

• There is no Negative value in rule creation-  This drives our team crazy.  If Connectwise could put in a value that was “NOT =” or “NOT” we could RIP UP the workflows into something even more amazing.  WE have learned to work around the formula creation without this basic programming command.  We do not understand why it is not included- but we want it!

This blog is pretty brief on a very broad subject.  I am testing the waters to see how many users out there comment and are looking for some input on this subject. I hope to hear back from you guys on what is working for you with Workflow Rules and possibly being able to help one another!

Walking through a simple technology rollout:

Let’s explore a relatively simple IT issue and solution.  Let’s look at how an IT manager might introduce the solution, project plan, implementation plan, training and maintenance of the new solution.  We can use the example of the Blackberry Enterprise Server (BES).

As the IT manager, your company has begun to move into new markets.  The company has begun to acquire smaller firms with a more disparate sales team.  Not to mention that as the senior executive have begun to meet with the newly acquired companies and explore other markets, they are traveling often.  The sales team and executives are missing out on critical communications because they are only checking email over their VPN connections on the laptops they carry.  Many sales people cannot get wireless data signal in some of their client areas and are out of the loop for hours at a time.

POP email is used some, but the security and overhead of the firewall and mail systems is making this an issue.  POP does not offer the option of calendar sync either.  People are clamoring for an easier solution.

BES is an easily integrated software solution that uses a minimum hardware set in order to integrate existing mail systems such as Microsoft Exchange in order to deliver email, calendar and tasks systems to handheld phones over the air with security and centralized management.  Research in Motion provides the following notes on BES:

• “Organize email messages that require follow-up with the use of flags, as they do in Microsoft® Outlook®1
• Easily access network drives using the remote file explorer directly from their BlackBerry smartphones*
• Open and forward calendar appointments, including attachments1
• Browse folders on the BlackBerry smartphone to view and attach files to email messages*”, (RIM, 2009).

With a need identified and a solid solution in hand, an IT manager should research the cost of the system and confirm integration points.  The cost of a BES server can be mitigated in many ways.  If there is already a virtual server farm in place, a new instance of a server would suffice and not cost more than the operating system license and the BES software and user licensing.  If there is no virtual server option, then a true hardware server may need to be purchased.  Hardware should be planned out based on best practices from the software vendor.

The software vendor will also discuss best practices regarding software interaction.  Blackberry Enterprise Server 5.0 will not integrate with Exchange 2000 or run on Windows NT 4.0.  If additional infrastructure upgrades need to happen, then these should be considered when designing the plan and understanding ROI.  For the sake of our project, we determined we need a new hardware sever running Windows Server 2008.  The existing mail server is Exchange 2003 and all smart phones are compatible with BES v5.0.

It should be stressed that no IT manager should ever present hardware and software for approval before creating a project plan for implementation.  Many projects are killed mid stream or after the hardware is approved but when the senior managers see implementation costs for labor or downtime.  A well defined plan should include hardware and software, hours and interruption schedules.  In order to gain approval, it may be necessary to project the lifecycle of the solution and discuss ongoing maintenance fees or costs for expansion of the systems past current capacity.

At this point we will provide a project plan for implementation of the systems that include a well defined schedule for milestones and possible break points.  Each break point should include a backup plan for fallback.  Fortunately, a BES install is relatively easy on interruption to production systems.  Once the plan is approved by the senior managers, it is time to consider training of end users before the systems are even installed.

Training should be geared toward end users and should focus on the key pain points identified in the scoping of the project.  If the majority of the users want to be able to wirelessly sync their calendars and integrate to a central mail system, then the focus should be on those feature sets.  It is important to begin to float documentation or provide lunch and learns before the technology is rolled out to everyone.  This allows people to get a feel for what is coming before it is implemented.  Providing ongoing training in the form of online content or additional training sessions is critical to ongoing adoption of the technology.

It is time to move on to implementation and support.  Implementation should be a time when all stake holders are well communicated with.  The best implementations are ones where you pull he tablecloth out from under the china.  No one should know you did anything.  IT managers should provide onsite or highly available support during the first 24-48 hours of a system change or installation.  This support provides a smoother transition and can often mean the difference between long term adoption of a new system and having vocal stakeholders upset with what was over all a very good deployment.  It is often said that if a completely new network was installed and it worked 98% perfectly in the first week, but the president of the company could not print, then the entire project was a failure.  Perception is reality.

The success or failure of a successful implementation creates touch points at many levels.  An IT manager must manager their technical staff to research, design and implement the right solution in a timely manner.  They must also communicate with internal and external stakeholders to confirm budget, ROI, design specifications and time tables.  Once all is said and done, end users must be trained and the systems must be maintained over time.  All of these factors must be considered and executed with little margin for error because of how the perception of the project effects its outcome regardless of reality.

Quick Study- System Development Life Cycle. Computerworld. Retrieved July 12, 2009 from http://www.computerworld.com/s/article/71151/System_Development_Life_Cycle?taxonomyId=011

Blackberry Enterprise Server v 5.0. RIM. Retrieved July 5, 2009 from http://na.blackberry.com/eng/services/server/5/benefits.jsp

Delegating Without Losing Control. TeamTechnology.co.uk. Retrieved July 5, 2009 from http://www.teamtechnology.co.uk/soft-skills/project-management-training-part7.html

Part One- Setting up the Story-

One of the most difficult areas for a company providing services is how to track employee time against accounts.  There has always been a struggle between management and the personnel who provide the service.  The evolution of the IT Consulting industry has made the tracking of time more difficult.  In order to understand where we are today, I believe it is critical for us to look back and where we came from. 

IT Consulting – at least for the SMB space- began with a few rogue administrators who helped their friends or parents with their business IT needs.  These folks began to branch out on their own and work for a few small companies at an hourly rate.  Microsoft and other developers such as Intuit and RIM found an untapped market in the SMB space.  With the advent of Small Business Server, BIS and QuickBooks- many small business found electronic communications and finance more palatable and began to need strong IT consulting.

As admins began to delve into this world, they would bill companies by the hour.  Most of the work was done from a reactionary or project position.  The client would request work and admins would show up to perform the task for an hourly fee.  This worked well until there began to be growth in the market and firms began to employ multiple consultants.  Being able to predict revenue stream was difficult.  Some firms began to sell pre-billed blocks of time.  Tracking this was difficult and many companies did not have a good method for tracking the time of their consultants.

I know that I had worked for a firm that tracked all time in Outlook and Exchange.  Other firms tracked time in spreadsheets and Word documents.  The need to track time was essential because of the billing at an hourly rate.  The problem was that entering time was difficult and was not a part of most IT administrator’s culture. 

Enter companies like Connectwise and Alert- These firms were able to create a time tracking product specifically for IT consulting firms in the SMB space.  Now the SMB IT market was in the same boat as legal, accounting and other service verticals.  There were industry specific pieces of software to aid in their tracking and delivery of service. 

The Connectwise revolution was tracking on the cusp of an even larger movement-  the shift from billing by the hour to billing as a flat fee service.  Much like the pre-billed blocks of time- Managed Services was a focus on a flat fee for all the needs of a client.  The need for tracking time was still critical- but different.  Rather than losing revenue for time not accounted for, the ability to track the profit margins on accounts for flat fee clients was now the focus of attention.  All of this seems simple if taken in a homogenous billing system.  But- as firms shifted from hourly to flat fee, there were challenges in how to track time, reinforce the need for time tracking with consultants and ensure effective rates were measured against hourly bill methods in an accurate fashion.

Part Two will discuss the solution to entering time for firms focused on an hourly model and the setup for tracking time and employee satisfaction for Managed Services Firms

The formation of a scalable- functional AppDev department…

We are redefining our Application Development business line.  I have been asked to head up the efforts to sort out the bodies and set solid direction.  There are so many places to look, so much to digest.  I believe we have been able to break down our needs into a few core pillars:

• What is our development philosophy
• What SDLC model do we use
• What type of work are we looking for
• What skill sets does the team have
• What skills will we need
  • Now
  • Next year
  • In 3 years
• What tools do we use to:
  • Code
  • Define Scope
  • Communicate with clients
  • Define and track projects

We are currently trying to understand the difference in SDLC and development philosophy.  I am not sure what the difference is in Water Fall vs. Agile.  We understand the concepts- I would think Agile is a philosophy where Waterfall is a methodology for execution. 

It is apparent that our current project tracking systems in Connectwise were not built for the type of projects an application development team executes.  We would like to explore Base Camp and some other interactive, web based project management systems.

One of the most important parts of this will be the examination of our team and what they can do.  In order for the rebuild to work, we will need to focus on the abilities of the team and define where we can generate the most opportunity for our dollars.  We absolutely need to get a skills inventory from each member and focus on how that will define the line of business. 

Very exciting-  More to come….