We are a flexible company that adapts to the services clients request. Our expertise lies in all aspects of IT Project Management, Quality Assurance, Business Systems Analysis, and Business Continuity. We practice doing the work ourselves, and we teach people how to do the work. We focus on "soft skills" because there is a lack of training offered in this area. By contrast, the "hard skills", such as programming languages or database administration or network administration, are generally available from a host of training providers. In past projects we have observed excellent implementations of poorly conceived requirements, which is why we decided on our "soft skills" focus.

We continue to work on hourly or daily consulting contracts to do the work in each of the 4 competency areas listed below. We also continue to develop software, but there are so many different languages and systems used by prospective customers that we generally shy away from this except to supplement other services. We can contract directly, based on bi-weekly time & materials invoices, or we can sub-contract via an agency such as Ajilon Consulting, depending on customer preferences.

We started out with a focus on contract Project Management services, which is why we named to company PM4HIRE. This is still the core of what we do: we believe in the responsibility to pull all aspects of a project together and to deliver quality results. We take Project Management seriously: either you run the project or the job is misrepresented and should be represented as a Project Control Officer or a Team Leader. We use the PMI standard PMBOK as a starting point for a more comprehensive set of Project Management Life Cycle methodology. We also believe that the Project Manager, more than any other person, should take the lead in making sure that the requirements are fully understood, that the quality of the development is not compromised, and that the resulting software system helps the business to survive disaster events.

We have always focused on the formative side of projects to dig up the proper scope for each project. The actual implementation can often be easier once the full scope is laid out, because the change management issues that dog so many projects tend to be minor issues if you start out right. Therefore, starting out right has always been a cornerstone of our Project Management methodology. We continue to emphasize that, while the planning and tracking processes are important, this has to be in the perspective of implementing a solution that satisfies the true business needs. Who really cares if a project comes in on time and within budget if it is not a system that meets the true business needs? While this may be assumed in PMBOK, we would rather not leave anything to chance in terms of what a Project Manager should focus on.

We share many of these concepts in our Project Management Basics training seminars, and we remind you of these provisos when we present our PMBOK based Project Management Practice training seminars. There is another element that is just as important: to manage the conflicts between projects that require the same pool of resources. We have worked on Project Management Office roles and responsibilities, and on the development of project portfolios and work management systems. This is another complicating factor: while projects may be unique initiatives, they are seldom executed in a vacuum, even though that might seem to be the perception many people get from PMBOK. In fact, you have to understand the mechanics of how to manage an individual project before you can appreciate the complexities of managing many projects at the same time. In contrast, in many companies Project Managers seem to be in competition!

We also believe that the Project Manager should spearhead the procurement process to assess whether it is better to buy a ready-made solution than to start developing in-house based on identified requirements. Procurement is a recognized responsibility in PMBOK, but again this is not something that is entered into by default. The risks and benefits should be formally considered, because there are major advantages to moving ahead based on a proven solution rather than to embark on a high-risk development with uncertain outcome, provided that the proven solution meets the business needs of the organization.

Please click on this linkfor current service pricing information. Thank you.

Defining the business needs of the organization is no small task. In fact, it can be downright complex, and as a result many initiatives are too narrowly focused on limited requirements to make a major contribution to overall business effectiveness. Over the years we have identified many pitfalls that should be addressed to overcome many, if not all, of these scope deficiencies. As a rule it is difficult to draw nice pictures of what the business needs look like, but the advantage is that you are less tempted to look for solutions while you are painfully aware of the limitations of your knowledge.

The most critical aspect of any project is to have a good understanding of what is required to operate the business more efficiently. Only in full knowledge of what is required can you begin to prioritize what parts to address in successive projects, as it is rare that you can do it all at once. If you jump the gun your chances of starting a doomed project increase dramatically. Sometimes you do not start at the 'critical' applications, but you implement key support applications that make more important applications possible. This leads to the concept of program management in order to justify a series of projects (some that may not even be profitable on paper) in order to achieve a greater objective in stages.

When you have a good handle on what the business needs to succeed, you must address the operations staff that are expected to make use of enabling technology. Remember that it is not software that delivers the results, it facilitates the delivery of results provided that the people working in that business are served by the software. We use a proven, down-to-earth methodology for the evaluation of business requirements to elicit the departmental use-case needs. We do not use the graphical representation popularized in recent tools because we are concerned that this may compromise the analysis by putting too much emphasis on the presentation of what is being identified. We focus on general principles as we drill down to define user needs and wants. The latter are important motivators to get people to produce.

You need to develop the functional requirements and non-functional requirements that are essential to the design of the application software. Based on what is asked for, you may need to do a feasibility study to make sure the benefits justify the risk of development (or procurement). You may need to develop models to study the usability of the concept, or to simulate the operations impact, to make sure that the functional requirements are solid before the detailed design is finalized. For a phased work program you may need to consider consequences of how successive layers of functionality are phased in. This is where the Project Manager must have a good grasp of the big picture to understand how an individual project contributes to the overall business applications development program.

Please click on this linkfor current service pricing information. Thank you.

In the past couple of years there has been a major shift in emphasis on Quality Assurance. What we have learned from production QA is that you cannot achieve quality by controlling what goes out the door. You must achieve quality by streamlining the production process itself. In the context of software development that means incorporating quality initiatives throughout all workflows in the SDLC. This is another opportunity for a Project Manager to make a difference. If these QA initiatives are not budgeted for, then the temptation to cut costs will override the intentions of delivering quality results.

The focus of the effort to ensure quality results has to be shifted from testing the delivered code to making sure that there is a solid audit trail of effort aimed at preventing errors. Code errors are almost unavoidable, but requirements errors can be avoided (which is a good thing, because they are very expensive to fix). Basically that means producing detailed documentation of what you do at each stage of the project. Some people argue that this is a waste of time and money, but a funny thing happens when you write down what you plan to do: it tends to jump out at you what you know vs. what you do not know. In many projects eliminating the 'do not know' issues can make all the difference. Once someone makes a snap judgement to go one way or another 'for now' can cause real problems to be buried in code, never to see the light of day again. Unfortunately, the application does not do what it is supposed to do.

We know it is a bother when you document the things to do in great detail and people jump up and down that you are not doing the right things. One way to look at that is that sooner or later someone will discover the bug that will by then be buried deep in the integrated software. While it is inconvenient to stop work to attend to an oversight, there may be serious and costly ramifications from allowing a bug to pass into production. When the issue is never documented in the first place it is unlikely to be tested, or it may not be recognized as out of line. While you can establish a QA Governance function to watch out for poorly documented software projects, the real issue is Project Management professionalism that should prevent this from happening in the first place.

In our Quality Assurance practice we emphasize to use every opportunity for QA involvement early in projects, to capitalize on preventive opportunities as well as to make sure that all requirements are reflected in testing materials. We have a comprehensive QA methodology that has proven to be effective for manual testing and that provides an organized foundation for automated testing. No matter how you slice it, testing is a tedious and often expensive effort, and when problems are found in testing it is always costly and stressful to get bugs fixed. There is never a guarantee that all the bugs are found in time before the rollout: often testers work from incomplete specifications, unless our methodology is fully implemented.

Please click on this linkfor current service pricing information. Thank you.

I want to make it clear that I have never actually had to participate in a disaster recovery effort. What I have been involved with is the research and simulation of disaster events in order to devise plans to minimize the impact of a disaster. I am also a firm believer in looking after people's safety first, and to discourage heroic efforts to save company assets from a burning building. You do that by replicating critical assets for off-site safekeeping, not by having people in harms way, and ideally by not locating a business where the risks of a disaster are higher than normal. You can never be totally protected from all disaster risks.

We developed a proprietary methodology called BIRP (Business Interruption Response Planning) that is a step-by-step approach to identifying and mitigating risks and consequences as much as possible before you have to depend on managing an actual disaster event. In fact, a key component of a disaster response is to make sure everyone gets out safely, before we consider how we can re-route business activities to those centers that are not affected by the disaster. Assuming that we have provided for adequate backup facilities and that we have taken regular copies of critical assets the focus of the plan then shifts to bringing the backup facilities on-line. Based on research on companies that survived a disaster vs. companies that went under, it is possible to dramatically improve your odds for survival by implementing common sense preventive measures, and by documenting a step-by-step response plan.

We explain the fundamental steps of BIRP into 6 phases of development called RECIPE, which is short for Risk Identification + Exposure Assessment + Consequences Analysis + Impact Analysis + Prevention Actitivies + Execution Activities. The latter imply that an incident took place, but as we explain in our seminars you need to periodically simulate the execution to make sure everything is in place to deal with an emergency. It is not an attempt at being cute: it is meant to indicate a right way of doing things and to look for mitigation opportunities along the way. For example, a high volume and critical transaction system can be real-time mirrored to an off-site location that is unlikely to be affected by a disaster that affects the primary location. This kind of process has to be in place in order to be able to execute the necessary steps to transfer business activities to the off-site backup location so that you can resume near normal business operations. The execution steps will be customized to make it so based on what backup is available, and how employees can work with those backup facilities, and how soon after a disaster.

BIRP cannot possibly address everything that might go wrong: a disaster of 9/11 proportions is difficult to plan for, let alone to execute a recovery plan. Some disasters like 9/11 were unforeseen and might never be fully planned for no matter what process you use. Some companies with disaster plans based on lesser events managed to recover business, even a company like Cantor Fitzgerald that saw its WTC headoffice destroyed with an appalling loss of life. Other companies in neighboring buildings that were far less affected went under as they did not have a plan for dealing with a major business interruption. That is the difference planning makes, and why any new application system must have business continuity provisions built-in.

Please click on this linkfor current service pricing information. Thank you.