Any work done involving IT tends to have challenges with quality, time, and cost. \u00a0Yes, I did just list all three factors that go into any project. \u00a0The problem with many projects is that adjusting one area seems to have little effect on the other two. \u00a0Adding more to one leg of the stool can even make things worse rather than better.<\/p>\n
How often has a project had money poured into it only to prove it is a case of throwing good money after bad? \u00a0How often has a project extended the timeline only to have to extend again a few weeks or months later? \u00a0One way to help in all three areas is to use blended resources.<\/p>\n
Many large companies and vendors offer this approach. \u00a0However, when we outsource IT, it seems that teams tend to be too top or bottom heavy. \u00a0Here are some things to consider when judging blended solutions.<\/p>\n
<\/p>\n
The IT resources assigned to outsourced projects often fall into one of two categories. \u00a0The low-cost team is a low skilled, low experienced team at a low cost; that struggles to meet dates and milestones. \u00a0The elite option is a strong, experienced team that eats up a project budget way before delivery. \u00a0Both of these approaches can work, but a proper balance is going to give the best results.<\/p>\n
A balanced approach may seem like common sense, but it is not the norm in project implementation. \u00a0In general, any IT project is going to need some experienced, skilled, and more costly resources to start the project. \u00a0These are architects, designers, and analysts that should be putting together a good plan for the project. \u00a0If you are building a house, these are the people that create a blueprint and ensure that the design is viable (structural integrity, proper allowance for electrical, air\/heat, etc.).<\/p>\n
The lower cost implementors (entry, beginner, and mid-level roles) are not needed during this phase and rarely can do much other than prepare for the implementation phase. \u00a0Once you have a plan, the IT “veterans” are over-priced to do the development, and thus you switch to lower cost implementors. \u00a0The veteran leadership still plays a role, as they should be keeping tabs on the implementation. \u00a0This periodic check-up approach ensures that the designs and requirements are followed during implementation. \u00a0However, the time\/input of these veteran resources should be limited.<\/p>\n
The formula is simple enough, but it is easy to get off track. \u00a0The most common problem is that the veterans brought in to do the design work do not do a thorough job on the design. \u00a0Failing that, they may not\u00a0adequately communicate to the implementors. The lack of careful design is often due to a lack of understanding the business goals and requirements during the design phase.<\/p>\n
If the people doing the design and requirements work cannot explain the “why” of the project and the problems that are to be solved, stop. \u00a0Either educate them or find people that can, or do, understand.<\/p>\n
To solve the communication problem, make sure you have the implementation team or representatives go over the requirements\/design. \u00a0This review is so they can clarify any confusion. There should be clearly defined deliverables and milestones to hit. \u00a0The deliverables will help the implementation team know specific targets that and features to create.<\/p>\n
Once the plan execution starts, make sure the designers are checking in on progress. \u00a0They should review deliverables, and also check in periodically on work. \u00a0These check-ins will give another viewpoint as to how the implementation is proceeding against the design. \u00a0They might also provide help with problems that slow or block the implementation team.<\/p>\n
A clean cut-off from design to implementation will keep the higher priced designers from spending too much time bleeding over into implementation work. \u00a0Involve the senior resources as a sounding board for QA resources to help ensure the design is properly tested (or include a QA designer in the early process to give quality a voice throughout the project life cycle).<\/p>\n
Code reviews or milestones\/checkpoints with clear deliverables are an excellent way to keep the implementation phase moving smoothly and on track. \u00a0Minor adjustments and course corrections are much easier to absorb into the budget than large “pivots.”\u00a0 Keeping senior resources involved can avoid cases where you find that a lot of work just went into taking the project in a wrong direction.<\/p>\n
Sometimes the problem seems to be out of your control. \u00a0You might either lack the tech savvy to put together resources\u00a0or\u00a0be at the mercy of a vendor that is doing the project. \u00a0No matter what your level of control or involvement, here are some things you can do to get the best blend of resources on your project:<\/p>\n
A project that has well defined and regular deliverables will be more likely to be\u00a0adequately staffed. \u00a0Concrete targets will make it easier to staff for each step of the project.<\/p>\n
Fixed bids and blended rates are often used to simplify accounting. \u00a0However, forcing a measurement of each step, even if only in percentages, can help push for the right resources at the right time. \u00a0Squishy billing leads to squishy implementation.<\/p>\n
No milestone should be a simple sign-off or rubber stamp. \u00a0Make sure there is validation included so a milestone is a line in the sand that can stand on its own. \u00a0I push for each milestone to include demo-able deliverables, \u00a0Thus, there is always a way to base conversations about progress on something concrete.<\/p>\n
Even if you don’t know an architect from an incompetent hacker, ask for a breakdown of the team roles and assignments. \u00a0Taking this step will push the provider\/vendor to at least think about properly using the resources. \u00a0As a bonus, you will appear savvy to them by asking the right questions. \u00a0This can lead them to be more thorough in staffing your team than they would be otherwise.<\/p>\n
You might become a high maintenance client, but that’s ok. \u00a0Ask questions about how the project is going, how cost and quality are being managed. \u00a0Do not be afraid to ask for answers you can understand. \u00a0Clarification should not be a burden on a vendor. \u00a0A project that is being run properly can be explained by anyone. \u00a0Lack of IT knowledge should never be a problem for the listener.<\/p>\n
For example, If you don’t understand why the team has a continuous integration specialist (or any other title) then ask what that provides to the project. If it can’t be explained, then maybe that role isn’t needed. \u00a0Maybe the vendor does not understand what that role provides. \u00a0If a role can’t be defended it may just be overhead. \u00a0Ask questions and you will see some surprisingly positive results.<\/p>\n
<\/p>\n
If there is a Golden Rule in IT, it is “ask and listen.” \u00a0Whether this is your first project or you are a seasoned IT veteran, your best bet for success is to understand what you are getting into from the start. Make sure the team members\u00a0understand the goals. \u00a0Make sure they have skill sets that make sense for the tasks. \u00a0Keep an eye on progress. \u00a0Blended resources can be a great solution to complex project needs. \u00a0However, they must be used wisely. \u00a0If you take these actions, then your project will be much more likely to succeed.<\/p>\n
<\/p>\n