IT Project Blog

Best Information Technology Jobs

The poor economic climate and disappointing employment history of the past three years has led to many doomsday predictions on the likelihood of an upturn. Thankfully, a more optimistic article on the employment outlook in IT sector was published on globalknowledge.com. In “Top IT Jobs for 2010 and Beyond”, a rosier forecast of our industry is given, citing the increased demand for what the author, Randy Muller, calls the ‘critical IT jobs’. Let’s take a look at the list of roles that will be in demand in the coming years and examine certain reasons that justify this hopeful position.

First, let me say that as a practice and field of study, project management exhibits a certain resiliency, even in tumultuous economic times. Why is that? Because it is the job of a project management expert to solve the problems that seem to rear their ugly heads during such climates: resource limitations, tight budgets, risk mitigation, and the list goes on. The very definition of this field means knowing how to get things done despite these limitations.

So, if you're a project manager, a program manager, or a business analyst (or perhaps you play another pivotal role on a project) and you are facing difficult economic times, take heart! The way to market yourself to employers is as a money-saving, issue/risk controlling, project guru. Show the value that you will bring that will far outweigh the salary you demand. Easier said than done, yes, but it is possible – and companies are looking more and more to experts who can help them do just what you have been doing throughout your career.

Just take a look at this list of the best information technology jobs that we introduced at the start (in alphabetical order):

• Computer Forensics

• Database Administrator

• Information Systems Auditor

• IT Security Manager

• Network Administrator

• Project Manager

• Software Engineer

• Virtualization Engineer

• Voice Specialist

To hand-pick a few out of this list, think of the following: information system auditors save the company through compliance, IT security managers mitigate the risk of costly cyber-crime and downed systems in the workplace, virtualization engineers save costs by implementing a system of virtual machine environments that don’t require brick-and-mortar datacenters, and as you already know, project managers are responsible for being rock star money, time, and resource savers across the board!

It’s a big relief now that we’re starting to see more confident trends in employment in the IT sector. The U.S. Bureau of Labor Statistics is a great resource you can use to track the industry whether at a glance or in detail. If you are not in one of the best information technology jobs listed above but think you’d like to investigate further, feel free to email me (kthomas@nuwave-tech.com) with any questions you have on what a day-in-the-life might be like.

Because many of these jobs require following industry standards of behavior and performance, it’s important to stay current and marketable in your field by getting and staying certified. For project managers, the PMP and CAPM are excellent ways to position you and your expertise head and shoulders above other applicants. The same is true of the CISM and CISSP certifications for IT security managers. Take a look at the referenced article for more details or use our comments section to post any questions on how to go about pursuing your certifications.

Do you have one of the best IT jobs or do you hold another position in IT?  What do you think is the best information technology job?

Agile Software Development Projects: Pros and Cons

There are many ups and downs to agile development. This special IT Project Blog video post goes over the differences between iterative and waterfall development. It also gives an example of an agile software development project. The video is summarized below for those of you who can't watch at work :)

Agile development methodologies place emphasis on:

1. Individuals on the project team

2. Producing a working deliverable

3. Collaborating with business owners/clients

4. Responding quickly to necessary change

Advantages:

• Faster speed-to-market and increased business efficiencies

• A reduced budget

• Less defects in the final product

• Fewer “surprises” (scope changes)

Drawbacks:

• When change comes so quickly, it is difficult to avoid resistance from stakeholders and complications to end user training

• Because agile methods are not process-oriented and require quick response to change, a lack of documentation is often a primary characteristic

A customer story from NuWave Technologies shows just how successful agile software development projects can be. A US government agency had 23 disparate databases that needed to be consolidated into a single data store. NuWave completed this project in phases:

1. Consolidate the 23 databases into one central database, all while capturing updates from the individual databases
2. Replicate database on a SQL server and monitor performance
3. Convert old reports to new Crystal reports

If you would like help with one of your IT projects, email info@nuwave-tech.com or call (603) 594-9896 x251.

Share your agile experiences! What advantages and disadvantages would you add? What real-life examples?

6 Steps to Launch Your IT Project Over the Horizon

IT PROJECT BLOG GUEST ARTICLE--Mary Lee Gannon is the president of Gannon Group - a full service executive coaching, training and consulting firm that provides turnaround strategies for people and organizations by improving team performance, executive leadership skills, board performance, planning and project execution.

In business most ideas that never make it to completion die in the execution phase. Often this is because a simple plan was not in place from the beginning to insure that the pace of the project stays on track with the projected purpose and milestones. Below are six concrete steps that will help you define a project; evaluate if it is in alignment with your purpose and is viable to succeed; and determine who needs to be involved, the risk at play, and what the measurable outcome will be.

1. Develop a Solid Business Case and Create a Project Definition Form:
Ensure that your project is in alignment with the mission of the company, the agenda of your department and has support of the senior management team. Involve finance experts when putting together the case. Recognize early what is driving the project -- safety?, quality?, productivity?, cost? human development? etc. You may need to do a Risk Analysis, listing potential risks, rating them at high-medium-low and who will be responsible for managing that risk. The Business Case Form will include: Background to the Project, General aims(s), Initial Risks, Expected Outcomes, Benefits of the Project, Initial Estimates of Cost and Time. This Case may also be used to create a Project Definition Form for easy access to all responsible parties.

2. Write a Project Definition Statement:
Create this as part of your Business Case to prevent "creep"ing away from the purpose. Circulate this to those who do not need the detail of the Business Case.

3. Do a Stakeholder Analysis to Create Your Team:
Define each stakeholder, their interest in the project, what the projects needs from them, perceived attitudes and/or risks, and actions you need them to take.

4. Define Project Responsibilities:
Make a list of the tasks/responsibilities then assign which stakeholder will lead each one.

5. Create a Milestones Chart:
List each milestone to be accomplished, who is responsible for it and suitable units of measure whether it is days/weeks/months/years.

6. Create a Project Management Report:
This report will track the progress of the project and head off derailment. It holds a list of the deliverables from the Milestones Chart, a due date for each, a rating for each (ie: Red Flag - off plan, Yellow - will soon be off plan, Green - on plan or better), and action to be taken to bring the plan back on schedule. This is a key document to the success of the project. A schedule of when this Project Management Report is due and analyzed should be set up ahead of time.

Sign up for Mary Lee's e-newsletter with tips on big picture thinking by putting "subscribe" in an email to info@startingovernow.com. Or, get Mary Lee's free tip sheets on "Feel the Fear -- How to Build Self Confidence" and "Replace the Mad Hatter with Your Personal Plan" at http://www.startingovernow.com/Articles-and-Tip-Sheets.html.

5 Steps to Bottom-Up Estimating

In the last article, we went into detail about two of three popular methods for project estimating: completing a high-level feasibility analysis and top-down estimating. The third approach we introduced was bottom-up estimating. Out of the three estimation methods, this way is the most time-consuming but is also the most accurate. And, while it may not be appropriate for the sort of high-level estimates that are required in a project’s charter or initiation phases, it is invaluable during the planning phases as you develop your estimate of total project cost and a detailed project plan of all project tasks from kickoff to go-live.

These five steps will send you on your way to successful bottom-up estimating:

1. Identify All Project Required Tasks
2. Estimate All Tasks Identified in Your WBS or Project Activity Definition
3. Identify Task Dependencies
4. Identify the Resources Required to Complete All Tasks
5. Determine When Resources Should Complete These Tasks

Does step 1 – identify all project required tasks – sound familiar to you? What critical project management standard does it remind you of? If you guessed WBS, you’re right! The basis for bottom-up estimating is the all-important work breakdown structure. Because the WBS is a “breakdown” of all required project work, each decomposed project task is smaller, more manageable, and can be used to easily estimate the costs and duration of work. In fact, the PMBOK, 3rd edition describes the WBS as a critical input to project and program schedules and project organization overall. (For more information on how to create a WBS, check out the Project Standard for Work Breakdown Structures, also published by PMI – great resource!)

So now that we know what we need to get started with bottom-up estimating, 2 and 3 are the next logical steps – estimate tasks and identify their dependencies. Recall from the last article my insistence on the notion that, as project manager, you don’t have to be intimately familiar with the technology or processes being delivered in order to estimate effort required for work. That’s what your technical and business subject matter experts are there for. The process of creating a solid WBS and producing estimates from it is a perfect time to solicit input from all team members and stakeholders to ensure

a) their buy-in to the work required, and
b) to provide a firm reference point for future change management.

In other words, there will be fewer occurrences of requests for a change in scope and work if everyone is clear on the work required upfront.

The last steps, determining the resources needed and when those resources will be able to complete tasks, are also needed to put an accurate schedule together. When considering resources, think about the number and type (experience and skill level) of people needed, equipment (hardware, software, etc.), as well as supplies. As was the case with steps 2 and 3, don’t be afraid to consult an expert on resource-related requirements -- possibly a project or program manager who has lead a similar project, or even your PMO team.

Once you’ve completed estimation of lower-level work packages in your WBS, identified resource requirements, and documented task dependencies, the one thing left to do is aggregate your estimates into totals for each deliverable. This bottom-up estimation process – identifying the work required for lower-level activities and summing them to approximate the work required for higher-level deliverables – is a great way to get more accurate scheduling figures for larger work packages.

Decomposing these work packages gives a greater level of confidence for your project plan and has a slew of benefits in the long run: project buy-in, less chance of budget overruns and scope creep, and more control over your project, just to name a few.

What is your experience with bottom-up estimating? Do you find it to be the most effective method of project estimation? Please share your thoughts and comments.

2 Ways to Do Accurate Project Estimating

In the IT Project Blog article “Creating a Project Schedule”, we opened with a discussion of how difficult it is to estimate the difficulty and length of time it will take to complete an IT project before you have developed an intimate knowledge of the tool being developed or of the exact business needs before they are fleshed out. To help put some framework around how to go about developing an accurate schedule and project plan with or without such knowledge, we’ll introduce three different methods for schedule estimation:

1. High-level feasibility analysis
2. Top-down estimating
3. Bottom-up estimating

We will cover the first two in this article.

 

1. High-Level Feasibility Analysis
The key to conducting a feasibility analysis is to understand that project scheduling, budgeting, and resource estimating is a continuous and iterative process. While it would be nice to be all-knowing from the project’s kickoff, that’s just not realistic. Instead, use the knowledge you do have to walk through these three steps to help generate high-level estimates despite limitations:

• First, document general high-level project requirements and overall business process needs.
• Second, identify potential solutions (think ideas, not technical resolutions) to high-level needs.
• Finally, investigate any potential constraints that may affect project execution.

Deliberately stepping through all three of these components, especially investigating constraints, to the feasibility analysis will enable you as a project manager to identify necessary start and end points. These scheduling estimates for your project and its resources can be dictated by other organization limitations. This makes estimating without low-level details more straightforward. Be sure to double-check that your estimates for fulfilling the project's high-level business needs are practical by consulting your PMO, other project managers in your department, or another subject matter expert.

2. Top-Down Estimating
The top-down method is also best applied during the project’s initiation or planning phases, when rough quotes are needed for charters, return on investment reports, and project proposals. Like the high-level analysis, this technique is also quick, but still generates estimates that the business and the project team can be confident in. This confidence is achievable even if you have limited details about project requirements. How? Here are two ways to make estimations with limited details about your current project:

• Consult Your Organization’s Project Archives Here is where maintaining a company-wide lessons learned database really pays off. Finding a past project from which you can draw similarities – the characteristics of the business need, the type of application development or enhancement, and so on – can be the starting point for estimating your current project’s schedule. Review actual budget hours for those projects and apply them to yours where there are similarities in effort. Finding a similar project gives you a good starting point for determining the effort required for your own.
• Start a Work Breakdown Structure Notice the keyword: “Start”. The traditional purpose of creating a WBS is to break a project’s work efforts into small discrete task packages, as small as you can, in order to create the most accurate work estimate possible. Well, in this case, the assumption is that you do not know the detailed work efforts needed. So, start by creating a partial WBS, only breaking down your deliverables to the first few high levels. After doing so, use a best guess (or the best guess of a team technical expert) to estimate the work required.

Both the High-level Feasibility Analysis and Top-Down Estimating are good techniques to be used during project initiation when very little is known about exact project requirements. However, since we’ve determined that estimating is an iterative process, how can you refine your initial approximations once you do know scope details? Bottom-Up Estimating is a perfect way to do so and will be discussed in more detail in the next IT Project Blog article.

Which method do you use? Which do you feel gets the most accurate results?

Successfully Building a Software Prototype

IT PROJECT BLOG GUEST ARTICLE--This article was written by Dave Nielsen, a project manager with over 20 years of experience leading successful projects. He's also the founder and principal partner in three O Project Solutions, a project management training company and the vendors of AceIt (http://threeo.ca). Dave Nielsen may be contacted at dave.nielsen@threeo.ca.

Prototypes are used to test or prove a wide variety of products. The classic example is the car prototype which automakers use to test acceptance of various design innovations on the car buying public. While automakers use prototypes to test marketability, many prototypes are used to test design feasibility and learn things about building them that will help the manufacture process should they wish to produce the prototype. Software prototypes can be used to prove both marketability and feasibility, although the market the prototype is tested on is normally restricted to groups within the organization.

Don't confuse a prototype with a pilot project. Prototypes are used to prove a concept, usually a technical or commercial one, while pilots are used to prove the delivery method. The concept cars auto makers show at car shows are a good example of prototypes, while the 10 Apollo missions which preceded the successful moon landing of Apollo 11 are good examples of pilot projects. Pilot projects can be used to prove a project approach and a technical concept but there is no direct connection between the two.

A software development project that includes a prototype as a deliverable will have plans for how that prototype is to be used and the building of the prototype will be a part of the design phase, or implementation phase of the project. User feedback will be used to refine the design of the final application or system before the actual build phase of the project.

Prototypes can be a great way to improve software development project results on two fronts: they can prove a software concept or improve on it, and they can teach the team valuable lessons about the best ways to develop the software system. Not all software development projects will be helped by producing a prototype however. The first step in determining whether to build a prototype or not is to determine how it would help the project.

Determining the Need
Software development projects which deliver new, custom, systems are prime candidates for prototypes. Let's take the example of an automated order entry system which will replace an existing paper based system. The order entry clerks will use the system to enter orders into the system via a PC and the new systems order entry screens. Order takers downstream will be taking the orders from the system using PCs and their order processing screens. Your team has gathered all the requirements for the system, including the speed at which the clerks enter the order and the speed at which the order takers process the order in the system. This set of requirements will tell you the information that must be captured on the order entry and order processing screens and the information that is to be displayed to the order processors. These requirements are clear but what isn't clear is the graphics that should display the information and how the information should be arranged on the screens. A prototype which will capture information from the order entry screen, display it on the order processing screen, and accept the keystrokes which will process the order can help the team determine the best layouts and graphics.

You are only interested in the effectiveness of the screens that your two groups of users will see in the example above. Screens don't need to be functional to ascertain their effectiveness (beyond inputting data). This will allow the project to restrict development activity to a few screens and functionality to capturing and storing the data that is input and still obtain all the information they need to develop a system that will meet the project's goals and objectives and be accepted by the user community.

Prototypes may also help development teams to determine the most efficient techniques and tools to use in development. Let's stick with our order entry and processing example. This time, instead of creating an automated system to replace a paper based one, we're leaving the screens in place and replacing the database and platform the system runs on. The current system supports a variety of orderable products which require different information to be captured and processed, depending on the product. A prototype will be useful for proving functionality can be reproduced efficiently on the new platform and learning the best development and testing techniques. This prototype should take a vertical slice of the functionality and reproduce it on the new platform, say taking the order for one product and processing that order.

The system won't appear any different to your user community so engaging them for the prototype isn't necessary. Your prototype must prove that the team can create the required functionality on the new platform and that the functionality is at least as responsive as the system being replaced. Your prototype should also provide you with information on the best techniques to use for development.

Prototypes can be useful for learning about new user interfaces, new systems, new software platforms, or new functions. Avoid using prototypes where you wish to learn the best approach to take to development or in projects that add to an existing system.

Designing the Prototype
Your prototype should be designed to meet a specific set of goals and objectives. Defining the screens or functions it should contain is not sufficient. Goals and objectives should include:

• Measuring user acceptance (screen layouts, etc.)
• Identification of required changes to interfaces or functionality
• Identification of best practices for design, build, and test
• Performance measurements to prove/disprove software approaches Training for any new technologies or tools used. The training referred to is in-house training, not vendor training

The above list is not meant to be a complete menu of goals and objectives and you probably won't need to meet every one of these in every project.

Choose the best set of screens to include in your prototype so that you get the maximum benefit from user testing. For example, where logging in is required across a wide selection of screens, include at least one with that function. The goal here is to produce a system with the fewest surprises for your user community. You may also want to choose screens that implement the most complex concepts.

Decide on whether you need to prove build methods or performance, or both, in your prototype. Proof that the new system can handle the transaction volume required and perform at the required speeds may be a priority, in which case the functions you choose need to demonstrate this. Choose the most commonly used functions in this case. Choose the simplest, least complex functions when you need to determine the best development approach and tool set. This is particularly important if you are dealing with a team with no practical experience working with a new platform. Choose the most complex and difficult functions for the prototype in the case where you are looking to learn the best practices for development and have an experienced team.

The prototype must be carefully chosen to fit the system architecture where that prototype will be used in the final product. This may mean that the prototype must deliver the core functionality upon which the rest will be built (e.g. transaction processing, messaging, etc.). Consult with the architect for the new system on the decision. They should be able to direct you to a core set of functionality that can stand alone, meet the goals and objectives set for the prototype, and be re-usable.

Building the Prototype
Start by choosing the right software development methodology for building the prototype. If your prototype will only consist of a few screens without functionality it won't matter what methodology you choose because the build time and effort will be negligible. Choosing the right methodology becomes important when the build will require significant time and effort. Building the prototype will be a different activity from building the production system so doesn't necessarily have to use the same methodology as that chosen for building the production system. There are 2 methodologies that lend themselves to developing prototypes because of their focus on rapid delivery and learning from the build: Srum and RAD (Rapid Application Development).

Scrum relies on an iterative approach to development, where the iterations are called "sprints". Scrum also has no place for a project manager so you can hand the responsibility off to a senior developer or analyst who is called the Scrum master.

RAD is particularly suited to developing prototypes because the methodology is based on using a prototype. RAD is based on prototyping and modeling replacing an intensive requirements gathering phase. RAD works best where the development teams are relatively small. Since you won't have the entire development team on board at this point, RAD is particularly well suited for the purpose.

Quality Assurance should be a part of the prototype build. Building a prototype which cannot be manipulated by the user community will add unnecessary time and effort to the project, frustrate the user community, and end up prejudicing the stakeholders against the project. Developer testing and system testing should utilize the tools and techniques established for the project. You may acquire a testing resource or two from your QA group or assign the QA function to a developer on the prototype team. Test cases should simulate the way the user community uses the system and exercise all the screens, fields, and functions in the prototype.

The prototype should be delivered to schedule. If building the prototype exceeds the schedule a root cause analysis should be performed to determine the reasons for the delay. Reasons may indicate a different approach to development, or that original estimates for the effort are inadequate. The reasons will trigger changes to the project plan in either case.

There are companies that specialize in building prototypes to order. Prototyping is a core competency for these companies so you may want to investigate outsourcing the build of the prototype to a company that specializes in building prototypes on the software platform you are using for your project. Your "build or buy" decision should be made using the best Procurement Management processes described in the PMBOK® Fourth Edition. Learn about these best practices by taking a PMP® Course or other PMP® Exam Prep training, then passing your PMP® Exam for your certification.

Prototype Delivery
The prototype should be subjected to User Acceptance Testing, or QA testing, or both. QA testing should precede User Acceptance Testing where both are indicated. User Acceptance Testing should provide a feedback vehicle and narrative type feedback, including suggestions for improvement, likes and dislikes. QA testing should be done using the test suites and test cases designed for the prototype during the build phase. These tests should include performance tests which will measure the prototypes ability to perform at the benchmarks established for it. This testing may require special tools or environments to be available for load, stress, and performance testing.

User feedback should be collated by screen and function (where a screen is shared by more than one functional group) to help with analysis. Systems analysts should exam the feedback and make changes to the screens as appropriate. The feedback should also be evaluated for its implications for screens not in the prototype. Common functions such as the login feature may need to be altered on other screens as the result of user feedback on the prototype. You may want to conduct a second iteration of testing to prove the changes. Don't plan for more than 2 iterations of UAT.

Use the projects issue tracking/bug reporting system to capture test results from the QA team. A failure of a test exercising prototype functionality should be corrected and the test re-executed. A failure of a test for performance, stress, or load should be analyzed for its implications. The fix to correct the failure may be simple, in which case it should be made and the fix tested. On the other hand, the fix may be very complex, or even impossible. There are companies that offer UAT services for prototypes. You may wish to outsource UAT to a company specializing in that area if you have difficulty rounding up actual users or you are prototyping a commercial web site.

The implications should be examined in this case. Can the fix be implemented in the prototype and still allow the project to finish on budget? Is there another way of building the system which would avoid the problem? Does the problem have any implications for the functionality not delivered by the prototype? The answers to these questions will have a bearing on whether the project is to proceed to the next phase.

The issues, problems, and learning derived from building the prototype should be gathered and analyzed by your systems analysts for their impact on the development phase. The results of the analysis should be an input into the planning process for the implementation phase of the project. Look for indications that additional tools need to be purchased or existing ones replaced. Examine the results for their impact on effort estimates for the rest of the development and testing tasks in the project. Learning from the prototype may indicate that building the system is indeed feasible but the cost will now exceed the benefits so rewrite the business case based on any implications for project costs.

Your prototype has gone through QA testing and may have also gone through UAT. You need to ensure that work isn't duplicated so will need to indicate the software has been tested before archiving it, if your prototype will now become part of the new system. You're now ready for your "go/no go" decision on whether to proceed to the implementation phase of your software development project.

Creating a Project Schedule

One of the must-have skills for a project manager is the ability to oversee technical projects for which you have little or no specialized technical knowledge. For experienced and new managers alike, difficulties arise when creating a project schedule and you have limited knowledge of the inner workings of a new software package, how to go about developing a selected application, or the time it may take to successfully address all of your client’s support needs. Even in these circumstances, is it possible for you to successfully create a well-defined schedule that gives management and sponsors an accurate picture of when their deliverables can be expected? To that question I give a resounding “Yes!”, and here’s why:

 

1) The role of project manager comes with its very own support team. 

There are a few major inputs to project scheduling that your skilled support team should help you to develop to ensure that you aren’t flying blind through the project life cycle. Here are a few examples:

• The Activity List – Your technical team can help you to break out each business requirement into related system requirements and lower-level tasks for completion.
• Activity-Scope Relationship – You and your business analyst (may be one and the same on some engagements) can tie each activity on your list back to original business and scope requirements to make sure there are no gaps in your delivery.
• Activity Duration and Sequence – Again, your technical team will assist in estimating how long each activity will take to complete, whether that task is design, development, or testing.
• Resources Required and Availability – Functional managers in a matrixed organization will work with you to determine which developers, architects, testers, etc. will be available to you and when so that you can sort out your project’s plan accordingly.

 

2) Project planning is an ongoing, iterative process. 

The project schedule is not a fixed, immutable document. It will often change slightly here and there to accommodate the following:

• New task duration estimates
• Issues encountered during design, development, or testing
• Scope changes initiated by the customer
• A more thorough risk analysis

Because of this nature of the schedule, there are no expectations of absolute perfection. With the help of technical experts and other support team members, you can use the inputs above – resource availability schedules, the generated list of activities, along with their durations and sequence – to develop a baseline. This baseline indicates planned start and end dates for project milestones and is used to track your team’s progress towards project completion.

As project manager, it’s your job to see the entire field of play, leaving the bulk of the technical details to subject matter experts, so that you can maintain focus on the big picture and make schedule tweaks where necessary to accommodate variables. Simply make sure to manage stakeholder expectations by maintaining a consistent plan of communication so that everyone understands the impacts that slight schedule changes can have on other dependent plans.

If you love food as much as I do, you can liken this support/lead relationship to the support a head chef gets from his kitchen staff: sous-chef, saucier, grill chef, pantry chef, pastry chef… and on, and on. While the head chef is the one in charge, he couldn’t produce as fine a result without his assistants, experts in their own right in their respective fields. Too, what chef doesn’t oversee each station and make changes to his dishes along the way? The same will be true of you as you keep an eye on overall delivery of your project and make room for changes as you go.

Since project estimating can be done in several different ways, what specific advice is there for you as you estimate tasks along with your technical team? The IT Project Blog will publish its next article on three different methods of project estimating: high-level feasibility analysis, top-down estimating, and bottom-up estimating.

3 Tips for Managing Virtual Teams

There’s a new TV show debuting this fall on NBC, the commercials for which I think are beyond hilarious. As funny as the ads are, the sitcom “Outsourced” is based on a not-so-funny reality – in some organizations are disbanded resources groups, laid off from domestic companies only to be reformed overseas at lower cost. The hilarity of the show lies in the disconnected communications characteristic of intercontinental teams. But whether this subject matter tickles or offends victims of modern-day downsizing, the fact remains that its inspiration – the difficulty in bridging the gap between two workgroups working miles away from each other – is very real. This article addresses the peculiarities of virtual teams and how to keep groups fully engaged and working efficiently as one integrated body, even if they are geographically divided.

Maybe your team hasn’t experienced a shift as drastic as the one portrayed on the pilot-episode where an entire call-center moves from Seattle to India. But “virtual” can be used to describe teams with members working in different states or even those divided into office and telecommuting employees. The reasons for this shift to using technology instead of traditional travel are numerous, and include:

• high cost of travel
• cost of maintaining a brick-and-mortar office building
• time wasted by employees stuck in commuter traffic

These are just a few of the incitements to recruiting virtual teams. Although there are many benefits to virtual teams, there are also numerous issues that result from spatial and cultural divides:

1. Delayed or infrequent communication
2. Limited trust in teammates to get their job done
3. Propensity for remote workers to be disengaged

Here are some tips to overcome these three potential deal-breakers before they cripple your organization’s virtual teams.

Communication
Compile and distribute a team contact list for your virtual teams that includes a phone, email, and I.M. userIDs for each team member. Insist on the use of an instant message client to facilitate real-time discussions. Hold regular conference calls or video chats to keep everyone on the same page and also to begin the foundations of great relationship between teammates. Here’s a warning, though: make sure these meetings are always productive with a clear agenda and purpose, otherwise it may have the opposite result of frustrating and isolating members of your virtual teams even more.

Trust
On-site employees can tend to feel like the ones shouldering the bulk of the responsibility. However, being 100% clear about each person’s role on the virtual team and what should be delivered by each workgroup is essential to mitigating a lack of trust. Clearly outlining expectations to be met by teams stateside and otherwise (or at home versus in the office) will help alleviate a lack of confidence and avoid confusion around who should deliver what. Be sure to schedule regular checkpoints, too, to make certain everyone is carrying their weight.

Engaging Employees
Create a process for on-boarding of new team members so that team building can begin early. A team-focused orientation program for virtual teams is a great place to instill a sense of camaraderie in the group and a sense of ownership can only grow from here. To strengthen engagement of members of virtual teams who aren’t as new, freely commend them for jobs well done and be sure to copy the entire team so that everyone can be involved.

These are just a few pointers for managing virtual teams. Across the board, while I don’t believe it’s always the best choice to ship jobs overseas, I do believe in the benefits of diverse and varied groups, a characteristic that seems inherent to virtual teams. To bring in some fresh perspectives and optimize your use of virtual teams, utilize the resources of an IT consulting agency. And don't forget to share your thoughts and experiences with us--leave a comment!

Adapting the Pareto Principle for Project Management

There are not many observable instances in our natural surroundings where we find an equal distribution of anything of value. Population, wealth, workplace productivity, even the harvest of a farmer’s plot – there is a concentration of produce generated by the minority that accounts for the majority of yield. This is just a way of re-stating the Pareto principle, a rule titled after its namesake who discovered the principle that, as managers, we’d be wise to apply in our own projects:

The majority of the effects seen in your projects will come as a result of a minority of the work that your team does.

The Pareto principle is the “law of the vital few”. More specifically, it asserts that by focusing on the 20% of work that most matters to your client, you will produce 80% of your project’s results. It’s extremely important to remember the significance of this principle in two specific areas as your project progresses: time management and quality control.

1) Time Management
One of the figurative wires on which project managers have to balance throughout the project lifecycle is that fine line between meeting ever-mounting requests of a hard-to-satisfy client with constraints of a tight project schedule. So, what do you do when stakeholders add nice-to-have scope, small requirement changes, or requests for functionality that won’t necessarily add value or efficiency to their business processes? Or how do you address a perfectionist developer who has a tendency to pour hours of unneeded development into product enhancements to please a particular user or business owner? Unreservedly discourage “gold-plating” by enforcing and educating your teammates on the Pareto principle.

To apply it in your projects, consider what we learned earlier: identify the 20% of requirements or functionality that will most meet the project’s original business case and avoid tweaks and modifications that add little overall functional value. Make clear the impact that frivolous updates have on the project schedule, costs, and the success of the chartered project. Reasoning with stakeholders and teammates in this way will often win them over to your side and will help to protect your timeline.

2) Quality Control
Ensuring the quality of a final deliverable through first-rate development and thorough testing and verification is a given, right? A more difficult task, however, may be prioritizing resolution of defects found during testing. In this case, the Pareto principle can also be applied when addressing system issues: 20% of the defects cause 80% of the problems. What does that mean for your team? Although it may be tempting to tackle the “low-hanging fruit”--defects that are easy-to-fix but not necessarily important to the business--it’s wiser to funnel the bulk of your efforts into addressing the more difficult issues. Isolate the more important 20% that will bring 80% or the majority of the benefits to your client. This focus will result in increased success of your deliverables and a greater level of stakeholder satisfaction. The functionality most significant to their business should be delivered with the least flaws. Once the more difficult 20% have been tackled, you can address those easy-wins with the confidence of knowing that you’ve already met the majority of your client's needs.

If there’s one thing that you can take away from this long-used rule, remember this: while I certainly don’t discourage working harder, being armed with the foreknowledge of the Pareto principle, you can channel your team’s efforts to work smarter. While not discounting the remaining 80% of work you’ll have to do after putting this principle into practice, your clients will thank you for prioritizing project tasks to meet the bulk of their needs first.

Project Lessons Learned Part II: The Who and What

The IT Project Blog held its first live webinar session yesterday – “Improve Your Projects: Learning From Past Mistakes” (watch the recording here). What a success! We discussed topics ranging from how to compile a project lessons learned repository for your organization to how to find value in the failures of past engagements. Thanks to all who were able to carve out time to join us and share in this informative, interactive discussion!

There were lots of requests yesterday from attendees to learn more about how to present project lessons learned findings after they’re compiled and with whom those findings should be shared. These were great questions! Let’s expand on the “who” and the “what” of presenting your post-deployment analysis. First, the “who”: You’ll find that those who are most interested in attending a post- project lessons learned session will fall into three main categories: sponsors, project team members, and clients. The “what” is a little bit more complicated and often depends on your audience. That being the case, let’s highlight what sort of findings will most peak the interest of each of the three attendee groups.

1)   Executive sponsors are often most committed to the success of the project because they were responsible for obtaining a budget for the work. That being the case, discuss in detail with them the profitability of the project’s end results. Depending on how soon after you hold a project lessons learned meeting, you may be able to capture data on the value that your project has brought to your clients. For example,

• Did your project improve data quality? If so, by what percentage?
• Did your project reduce vendor staffing? If so, how much did it save the company?

The key is to quantify your results to make it relevant to your sponsors.

2)   When soliciting and sharing project lessons learned with team members, be sure to discuss:

• Project scope (reasonable vs. unrealistic)
• How scheduling of project phases made their jobs easier or more difficult
• The effectiveness of post-launch support plans

Capturing their approval along with their concerns will show them you appreciate the work they put in to bring the project to a close.

 

3)   Clients and end users, like executive sponsors, will be interested to hear about the project’s profitability. In addition to that, they will likely be eager to share:

• Their personal satisfaction on how the project was managed
• The effectiveness of the communication plan before and during the product launch
• How receptive you, the project manager or service provider, were to their business needs and functionality requests

Drawing out honest feedback from clients is tough – if mistakes were made, it can be easy to begin playing the blame game; be sure to keep discussions useful and informative to maximize benefit for everyone involved.

I hope these tips help you generate ideas on how to make the project lessons learned sessions you hold relevant and useful to your team, clients, and sponsors. Remember, you will need their support for your next engagement so always emphasize the value they have brought to the project by including them in your project lessons learned discussions.

Again, the first IT Project Blog webinar was a resounding success – we can’t wait until our next session and hope you will be able to join!