Posted on

Should You Go Cloud?

That is the question…to cloud, or not to cloud?  I recently read an article by Sarah Fister Gale, found here: http://www.pmi.org/~/media/PDF/Publications/PMN0312%20cloud.ashx
It is interesting how many people go to the cloud without knowledge of security, back-up, redundancy, and so forth.  There is little doubt that the cloud has many positive attributes.  That is why cloud usage continues to experience robust growth.  However, too often people just assume the cloud is a magical solution with hardly any issues.  Well, that is normally the case…unless you happen to be my brother-in-law.  His company was utilizing a cloud hosted credit card processing service.  And things were great for nearly two years, until the cloud server went down and there was no back-up plan in place.  It took 3 days of hand wringing and lost sales to get back online.  In addition to immediate lost revenue, he lost long term customers.  The article above will certainly give you an idea on specific questions one should ask and a basic outline to help you make a solid choice for your cloud solutions.

�

Posted on

Project Portfolio Management

Project portfolios are helpful for grouping work and managing projects individually and as a whole. Many companies start out not utilizing project portfolios. Then, as the company grows projects become unmanageable and the need for project portfolio management becomes clearer. Portfolio management helps companies maintain efficiency and breaks project work load into manageable pieces. It is vital that whatever project management software you utilize, be sure it is scalable to include project portfolios. It is likely you will need it! There is way too much to cover in this short blog. However, a pretty good white paper can be found from Mosaic Project Services at the link below.

http://www.mosaicprojects.com.au/WhitePapers/wp1017_portfolios.pdf

Posted on

Trust Me, I’m a P.M.

An often overlooked step in the project management team is the project/client representative. The person responsible for being the messenger, intermediary between the project team and the client is a critical role. Larger companies pay professionals to strictly fill this role, while smaller companies often let the PM handle that role. This is fine in most cases, unless your PM is not good at customer relations. Customer relations’ professionals spend their entire day thinking of how to build trust, gain confidence, and maintain a relationship. Project managers spend their day doing this on some level within their project team, but it is not their main focus. If you are good at customer relations it will make the project run smoother because the client will have a certain level of trust. If you are not, the project becomes hindered. Why? Because, the client doesn’t have a needed level of trust in you, they begin to question your work. Now the client wants more status meetings. Maybe the client begins to micromanage your project and requires more of the project manager’s time and attention? This can quickly snowball because of one misunderstood statement that breaks a fragile trust. Whoever is communicating with the client, make sure it isn’t General Patton. While he gets the job done, in the project world he would make the job more difficult.

Posted on

Negotiating and Managing Project Expectations

One of the many factors in project cost overruns is due to setting unreasonable expectations. Whether working as a consultant outside a company or as a project manager within a company, all too often we become “yes” men to secure a deal or please superiors. We may win in the short term by getting the job or by delaying management’s wrath by telling them what they want to hear, but, in the long run, both scenarios are losers. As a consultant you land the gig and wind up with bad word of mouth advertising as being late and over budget. As an internal project manager you develop a reputation of being unreliable and/or overly optimistic. Instead, be real and upfront about duration and costs of expected projects. Give pushback to help set reasonable expectations. Maybe someone else will promise the moon? You should challenge competitors’ unreasonable assertions. You may still wind up losing the deal, but in the long run you will maintain your reputation and eventually land more deals because of it. Short term pain for long term gain is tough in this economy. What is your word worth and where do you go to get your reputation back?

Posted on

How to use Overtime in MS Project

Admittedly, overtime is a clunky feature in Microsoft Project.  I like the simplicity of Standard Time better.  But here are some steps to help understand and master overtime usage in MSP.

Start by assigning resources to your tasks.

  1. Right-click in a column header
  2. Choose Insert Column…
  3. Insert the ‘Resources’ column
  4. Enter names for employees that will work on each task

Assign cost rates to resources

  1. Choose View, Resource Sheet
  2. Enter currency rates for ‘Std.’ and ‘Ovt.’

Enter overtime hours

  1. Choose View, Task Usage
  2. Right-click and insert ‘Work’, ‘Cost’, ‘Overtime Work’, and ‘Overtime Cost’ columns
  3. Enter hours for the Work column
  4. Enter a portion of those hours that will represent overtime work

You will notice that the ‘Duration’ value shrinks for tasks with overtime hours, and that the ‘Cost’ and ‘Overtime Cost’ values are update accordingly.

 

–newshirt

Posted on

Do you like Project Robots?

You just buried your mom and returned from the funeral. You’re a Project Manager on a high profile project for one of the largest tech companies in the world.  It has only been one day since the funeral and you are still raw with emotion.  Now imagine that you get an email informing you that you are not getting a break from the loss of your mom, but in fact, your workload has been increased.  How about a spouse fighting cancer?  Need a little time?  No!  Instead, how about an increased workload?  Sound crazy? Well, imagine no more…these are true stories.  This brings me to an important point.
In talking with a friend of mine with 26+ years of project management experience about Agile vs. Waterfall methods, he said, “You can have all the methods and processes you want but it all comes down to personal relationships and human intervention”.  This gentleman was responsible for one of the largest SAP installations in US history. I was taken aback by the simple answer when he stated another simple cliché, “Take care of your team and your team will take care of you”, which means that they will take care of the project.
The examples given in the beginning of this blog are not meant to say that we shouldn’t be tough or suck it up.  However, besides being in my opinion morally wrong, it is flat bad for business.  Is the man whom just buried his wife still ready to climb that mountain for the team?  Or, is he waiting for the first chance to jump ship?
All too often we pay lip service to our employees, “Let me know if you need any more resources”, while completely ignoring the realities of life.
I guess the bottom line is we can keep on pushing the machine, but what happens when the machine navigator gets ran over?  Does the machine keep going and if so, who is driving…a robot?
Make sure when you ask someone if they need help that you don’t ignore the reality that is staring you right in the face — unless you like robots.

Posted on

Scrum Burn-down Charts

In the world of project management there are often disputes over Waterfall vs. Agile methodology.  Most people have a bent or preference and there is plenty of discussion whether Agile can fit within any typical Waterfall project.  However there isn’t much disagreement among Agile proponents on the need for a good SCRUM chart.  Check out the link below from a recent blog posted on PMI.org by Bill Krebs.  Bill has an interesting take on Tracking Burn-down Progress…

http://blogs.pmi.org/blog/voices_on_project_management/2011/04/tracking-burn-down-progress.html

Posted on

7 Things You Need to Know About Development Project Estimations

Whether you are a project manager planning for a smooth implementation of a plan or a project sponsor on whose decisions a project depends, you cannot escape from the fact that project estimation is essential to its success. In the first place, there are three basic requirements that a project must satisfy: schedule, budget, and quality. The need to work within these essential project boundaries poses a huge challenge to everyone in the central management team.

There are various aspects that affect project estimates, such as team skills and experience levels, available technology, use of full-time or part-time resources, project quality management, risks, iteration, development environment, requirements, and most of all, the level of commitment of all project members.

Moreover, project estimations do not need to be too complicated. There are tools, methodologies, and best practices that can help project management teams, from sponsors to project managers, agree on estimates and push development efforts forward. Some of these include the following:

  1. Project estimates must be based on the application’s architecture. Making estimates based on an application’s architecture should give you a clear idea of the length of the entire development project phase. Moreover, an architecture-based estimation provides you a macro-level view of the resources needed to complete the project.
  2. Project estimations should also come from the ground up. All estimates must add up, and estimating the collective efforts of the production teams that work on the application’s modules helps identify the number of in-house and outsourced consultants that you need to hire for the entire project, as well as have a clear idea of the collective man-hours required to code modules or finish all features of the application. Ground-up estimates are provided by project team members and do not necessarily match top-level estimates exactly. In this case, it is best to add a percentage of architecture-based estimates to give room to possible reworks, risks, and other events that may or may not be within the control of the project staff.
  3. Do not forget modular estimates. Once you have a clear idea of the architecture, it becomes easier to identify the modules that make up the entirety of the application. Knowing the nature of these modules should help you identify which can be done in-house or onshore, or by an offshore development team. Moreover, given the location and team composition of each development team that works on a module, it becomes easier to identify the technical and financial resources needed to work on the codes.
  4. Development language matters. Whether the development language is Java, .Net, C++ or any other popular language used by software engineers, team that will be hired for the project must be knowledgeable in it. Some development efforts require higher skills in these languages, while some only need basic functional knowledge, and the levels of specialization in any of these languages have corresponding rates. Most of the time, the chosen development language depends on the chosen platform, and certain platforms run on specialized hardware.
  5. You cannot promise upper management dramatic costs from offshoring. While there are greater savings from having development work done by offshore teams composed of workers whose rates are significantly lower from onshore staff, you must consider communication, knowledge transfer, technical set-up, and software installation costs in your financial estimates. Estimating costs is often more about managing expectations, but as the project matures, it should be clearer whether the money spent on it was money that was spent well.
  6. Project estimation software and tools help identify “what-if” scenarios. Over the years, project managers have devised ways to automate project schedule, framework, cost, and staffing estimates. Some estimation applications also have sample historical data or models based on real-world examples. If your business has a lot in common with the samples in the estimation tool, it can help you identify what-if scenarios and in turn include risks, buffers, and iteration estimates.
  7. Price break-down helps in prioritization. Breaking down the total cost of the project helps management decide which parts of a system should be prioritized, delayed, or even cancel. Estimating costs for a new project may not be easy, but project sponsors and managers must be able to know and agree on the breakdown of costs of development, technical requirements, and overhead.

By ExecutiveBrief -online resource on process management, project management, and process improvement.

Posted on

Success Factors in Knowledge Management

Knowledge management professionals must keep in mind that KM’s explicit end-goal is profitability while its implicit purpose is to empower participants through intellectual platforms and processes that promote learning and practical knowledge.

Knowledge, without a doubt, plays an important role in the success of any organization. In fact, in order to maintain a competitive advantage, modern organizations incorporate knowledge creation, knowledge sharing, and knowledge management into their business processes. The mere survival of many organizations hinges on the strength of their capabilities; moreover, companies form decisions based on their relevant knowledge of their business landscapes.

Thanks to developments in information and communication technologies, it is now easier to develop, store, and transfer knowledge. This capability is particularly true among organizations with global workforces. After all, international competition and globalization are the driving forces behind most technological innovations, and companies quickly take advantage of these developments when it comes to managing the creation and flow of information.

“Ultimately, leveraging relevant knowledge assets to improve organizational performance is what knowledge management is all about,” says Murray E. Jennex in his book, Knowledge Management in Modern Organizations (2007). However, in spite of the lightning-speed creation of new knowledge and the improvements in communication technologies, many organizations still find that their knowledge management practices are lacking. Specifically, within client-consultant relationships, knowledge transfer does not always translate into better performance by all project team members, nor does it always translate into the successful delivery of projects.

To be successful, knowledge management programs require more than simply conducting training sessions or transferring knowledge. Practitioners must always remember that KM’s explicit end-goal is profitability – while KM’s implicit purpose is to empower participants by providing them with the intellectual platforms and processes that promote learning and practical knowledge.

Here are a few factors that contribute to successful knowledge management initiatives:

  • Linkage between knowledge and economic performance – Knowledge management exists because it enables the organization to reach its business goals. Otherwise, there is no point in putting together all the best practices, tacit knowledge, and skill sets in a cohesive system that is accessible by all parties – when and where they need it. As business increasingly becomes more global, the competition for greater market share depends on the capabilities of its players to a certain degree. KM practitioners must be able to identify the business value of knowledge management in their organizations – whether it is to manage projects, provide back-office operations services or to give ideas on how processes can be better optimized – among others. In most consulting relationships, knowledge is the currency by which all transactions are made.
  • Setting and communicating clear objectives for specific organizational or project levels – Heather Kreech, the Director of Knowledge Communications of the International Institute for Sustainable Development has some specific ideas on this very subject. In her paper, Success Factors in Knowledge Management (2005), she states that knowledge-sharing works best when knowledge managers “gather and communicate knowledge at the project/activity/field level before [they] begin to aggregate up to corporate systems and general knowledge marketing strategies”. Having a specific organizational level or project group in mind, results in better designed knowledge management systems, training programs, and tools that can meet the specific needs of workers.
  • Having the appropriate systems and infrastructure – Ideally, knowledge is created, processed, stored, and archived. Managing the process of creating knowledge, communicating this knowledge to participants, and making knowledge available to anyone in the organization, means that an organization must have the right communication systems and data storage facilities. However, it is not enough to simply store knowledge as this knowledge must be found whenever it is needed. Thus, the availability of internal search facilities and computer-based training programs is critical.
  • Having the right champions – KM initiatives need project and process champions who can rally the support of everyone – from top management down to individual staff members. Having management support can result in the freeing up of resources – such as financial, expertise, and infrastructure – all of which are critical to the successful implementation of KM projects. Financial backing means that KM managers can implement training programs, hire both internal and external specialists – as well as acquire the required infrastructure to manage training programs. On the other hand, access to experts from either within or outside the organization, means better identification of knowledge gaps and training requirements, and more importantly, engineering training and communication programs that meet the said needs.

By ExecutiveBrief
Technology Management Resource for Business Leaders
http://www.executivebrief.com
¼/p>

Posted on

The Key Success Factors in IT Business Alignment

As business needs help set IT’s priorities, how IT departments align their solutions with business objectives hinge on a number of success factors.

The most pressing issue among CIOs, according to a 2008 survey by Society for Information Management (SIM) is the alignment—or misalignment—of IT with business. As IT departments need to consolidate their resources, there is a growing concern among CIOs that doing so may not be so easy. One cause of this issue is that tech workforces are seen as merely solutions provider instead of as strategic resources to achieve business success. Meeting business expectations effectively should be the goal of IT, but more importantly, of business

There are several approaches that can be taken to align IT with business. Some approaches focus on the roles of individual IT contributors, while others focus on the needs of the business side and their position in the market. It is up to CIOs to identify key business needs and turn these needs into objectives that their IT organizations must achieve. CIOs also have the responsibility to build organizations that can deliver the right support to various project portfolios.

IT departments are there not just to provide computing solutions. Businesses will get more value from IT by considering their operational and strategic business needs. As business requirements help set IT’s priorities in terms of identifying resources, form insourcing and outsourcing strategies, and set up infrastructures, how IT departments implement their chosen approaches hinge on the following success factors:

  • Open communication lines. IT departments and their business counterparts should set up a communication system that actively involves all stakeholders. This allows IT to get a feedback from the business side to formulate the best solutions possible; on the other hand, an open communication line with their technical counterparts familiarize business decision-makers to identify and take advantage of the available technical knowledgebase for better organizational and market performance.
  • Business requirements analysis. IT’s exposure to business allows them to identify business needs that should be the key drivers behind most aspects of their operations. CIOs are best positioned to frame projects, infrastructures, and systems according to the needs of their primary clients. The success of IT as a business strategy is judged on how it helped in meeting business objectives.
  • Expectation management. Both sides should be realistic about their expectations of each other. This can be achieved through the two mentioned success factors: communication and requirements. Business managers should know the limitations of IT, and that solutions do not come in cheap, such that in-house resources for application development and maintenance may require engaging third-parties to fulfill business needs. On the other hand, IT should be aware of the technical—and sometimes, financial—limitations of business operations. For example, introducing new systems to the IT enterprise landscape means training batches of end-users which then result in additional work to include end-user documentation and training designs.
  • Organizational protocols and sponsorship. Internal protocols do affect the success of IT-business alignment. Sadly, protocols do not necessarily mean processes; protocols in most traditional institutions mean “just how things are done.” To navigate through layers of bureaucracy where it exists is to identify key personnel and project sponsors who understand and can articulate the justifications for IT projects as business strategies. Where all decision-makers must stamp their signatures in all IT ventures, CIOs should find the right people to champion their causes through coherent analyses of business needs and presentations of business solutions and the hoped-for success criteria.

At the end of the day, most of the work rest on the shoulders of CIOs, being the key figures that understand the business side of things and have the ability to translate business needs into technology solutions.

By ExecutiveBrief
Technology Management Resource for Business Leaders
www.executivebrief.com

�