Archive for ‘Project Management’

October 21, 2010

Project Information Management


Just about everything we do can be thought of as a project or series of projects.  In our professional lives, companies create their strategic plans and budgets based on a series of initiatives, programs, and projects which filter down throughout the organization.  And collaboration within organizations mostly revolves around the fundamental element of work today — the project.   When you think about using a technology platform like  SharePoint to facilitate the management of things like strategic planning and the project management process, there are a few different levels to consider:

1. Project Manager Level – scope of an individual

2. Project Teams – scope of an single project

3. Portfolio and Project Management (PPM) – more complex and broader reaching scope with executive level oversight

You also need to think about the maturity level and culture of your organization.  How formal is your project management process?  Do you have a formal methodology and certified resources?   Or is most of the work you do project management “light” with some structure, use of MS Project, team sites, and resources who become “PMs by accident”?   Or do you have a formal mature Project Management Office?   Answering these questions will help you think about what technology capabilities you need to help facilitate the project management process in your organization.   For example, the diagram below shows what technology you might leverage depending on how mature your organization is when it comes to PM.

For individual project managers, SharePoint provides a platform to help you share, manage, and secure information.  Fortunately as a PM, everything in SharePoint is really just a list (in simple terms).  And tracking things in lists is core to what PMs do everyday:  issues, risks, requirements, change controls, tasks, status, etc…   Unfortunately, many PMs just don’t understand how to leverage SharePoint to manage project information and use the technology as a communication tool to both project teams and upper management.  As PMs, we continue to use Word tables and Excel and email documents to each other.  We’re held hostage by our inboxes, methodologies aren’t always followed consistently, project artifacts wind up in multiple repositories including SharePoint, and project information and status lack visibility.

With that understanding, there are several things an individual PM can control and implement on a SharePoint site simply by educating yourself a little or getting some assistance from a resource who has some SharePoint knowledge.   If you want to take it one step further, you can begin to leverage your SharePoint site as a “project information management” dashboard as well.   However, I won’t go into more detail here in this post. As a reference, I am providing a link to a presentation (free-to-download) that I gave on this subject with screenshots and more insights:  http://www.slideshare.net/getrichieb/managing-projects-on-sharepoint-rich-blank-july-2010

I want to close by helping you think about what that ultimate vision is for leveraging SharePoint for project information management. The diagram below illustrates this vision.  It starts with information architecture and governance of the PM methodology to define what project information and artifacts are required and what metadata and content types are needed.  Instead of burying tables of redundant information in multiple Word or Excel documents, think about how you can surface those same rows & columns inside SharePoint.  Also, envision the ability to aggregate the project information you are storing in SharePoint lists across all project team sites.  Think about the ability to view and filter critical issues and status across projects, drive analytics and executive decisions based on the information managed by SharePoint.  Think about how you can leverage SharePoint to reduce overall risk of execution and ensure PMs deliver on time and on budget with a high level of quality.

Advertisements
September 30, 2010

Why is measuring a hard ROI for SharePoint just so hard?


Traditionally when it comes to implementing technology, the financial bean counters and decision makers have looked for hard dollars for the ROI of a technology investment. However, when it comes to SharePoint, it seems we have thrown a hard ROI out the window. In a manufacturing or factory environment, it’s generally easy to measure hard dollar costs of raw materials or labor costs or costs per hour. Centuries of economic theory and practice led to the pioneering of the “scientific method” in the early part of the 20th century by Frederick Taylor and Henry Ford among others. Implement “robot X” into the assembly line and produce more widgets and save on labor costs. We have also had a few decades of TQM (total quality management) which has evolved into many buzzwords all seeking efficiencies in productivity of manufacturing and supply chains. In Business School, I remember learning all kinds of management theory on these subjects and “generally accepted accounting principles” to calculate hard dollar costs and manage budgets to actual as well as profitability of goods sold. So what happened to measuring ROI of SharePoint and why isn’t there enough written on it?

I have read tons of articles on web 2.0, collaboration, and SharePoint. They evangelize about grand topics like innovation and creating opportunities through communities and connecting people through social sites. Some talk about the vision of enterprise content management being realized at an enterprise level. And some articles even try to address ROI and talk about the “downstream effects” of capturing ideas and information in blogs or wikis. Then we hear from executives and decision makers that evangelizing the technology sounds great, but all the benefits are “soft” and too hard to measure. Okay, so why not measure “soft costs”?

The reality is that all businesses have soft costs such as turnover, lost productivity, low morale, lost sales and missed opportunities. And any combination of those might drive soft cost dollars in your organization which can have big impact on your bottom line — sometimes just as much as the hard costs and other times even more. Many organizations simply don’t measure these types of costs because they don’t understand it or simply don’t have the capability to measure them. Or perhaps people are just focused on meeting deadlines without questioning the value or impact to the customer. Meanwhile, project management within many organizations seems like chaos, deadlines get missed, decisions are delayed, tiger teams get formed, and the insanity of our day to day work life continues. Projects that should take only a few weeks or a few months, takes 12 or 18 months to complete and quality suffers as does employee morale. You continue to wonder why things in your organization aren’t as easy as what we see on Google or Facebook. Then we recharge on the weekend, read the Dilbert cartoon in the Sunday paper, laugh and think of our own work environments, and do it all over again next week. All the while we continue to email each other on our smart phones and at best upload documents to a site on SharePoint. And if you’re paying attention, there are no doubt hidden costs in many of the things just mentioned.

In today’s economic climate, it’s time we take a hard look at dollars and sense and focus on driving analytics from a collaboration & information management platform like SharePoint. In my next series of blog entries, I’m going to focus on making measuring a hard ROI less hard and relate it specifically to real solutions implemented on SharePoint.

Tags: ,
September 17, 2010

Don’t Forget the Change in your SharePoint Investment


We have seen SharePoint sites pop up and virally explode.  We have seen SharePoint used in many cases as a basic document repository.  In some organizations, we’ve also seen SharePoint used for collaboration, project management, or even process improvement.  No matter how SharePoint is used in your organization, you’ve probably taken a standard approach to implement the technology with the typical project elements:

  • Identify business need or opportunity.
  • Define the Project.
  • Design of Business solution.
  • Develop new processes and solution.
  • Test, implement, and train.

Or maybe you’ve gone one step further properly planning and outlining your roadmap to build out a centralized SharePoint infrastructure with a clear migration strategy for your legacy intranet or fileshares or collaboration spaces.  However, the traditional approach we normally take to deploy technology has resulted in many non-believers and those who continue to under-leverage the capabilities of SharePoint and rely on the old ways of doing things.

Yes, it’s important to create a solid technical infrastructure.  Like building a foundation to a house, you need a stable platform that can scale and perform for users no matter where they are in the world. And yes, you also need good governance of the SharePoint platform to manage and support users and the growth in demand.  While a secure technical infrastructure and good governance are 2 keys to a successful deployment of SharePoint, there is still one thing missing.   A critical ingredient which is not discussed or blogged about much is the change management component that SharePoint requires to break old habits and fundamentally transform how knowledge workers approach their day to day.   When I talk about change management, I am referring to people but not necessarily referring to the social capabilities of the software.  I’m referring to how SharePoint as a technology can reshape the “industrial psychology” of how knowledge workers connect, collaborate, communicate, and actually get work done in today’s service-driven economy.   While there are a number of methodologies and approaches to managing change, there seem to be a few common themes among the different schools of thought:

  1. Assess your organizations readiness for change.  Is it incremental or transformational? Are people aware they need to change?  Is there a sense of urgency?  Do they have the desire?  Where is there resistance?
  2. Knowledge about the change and vision.  People need to learn new abilities and ways of approaching the same work with the new capabilities that the technology offers.
  3. Empowerment and reinforcement.  People need to take ownership and the behaviors need to be reinforced.  There needs to be some short term wins and long term vision and approach to make the change become permanent.

SharePoint needs to be seen as a productivity tool and not just a place to store documents.  For this to happen, building the best solution on SharePoint is not enough.  Training and adoption can’t be an afterthought that happen towards the end of the implementation.  Change management needs to be part of the plan and addressed up front.   At the end of day, SharePoint is a platform that is not just about information management or some broad concept like collaboration.  If you want to maximize your investment, don’t forget the change.  Ultimately SharePoint is about people and the ability to manage change throughout your organization.

Follow me on Twitter…

August 16, 2010

How to Staff Your SharePoint Project


Something that has been truly bothering me lately is recruiters or project managers or executives not knowing how to staff SharePoint Deployment projects or staff their Operations teams that support SharePoint.   Too often I receive calls from recruiters looking for SharePoint “Technical Resources”.  Rarely are they looking for people who know how to analyze business processes or manage enterprise information management platforms like SharePoint.    It seems recruiters want hands-on resources who write code and do everything else including administration and configuration.   Unfortunately looking for a jack of all technical trades is just not the best way to minimize risk when it comes to your enterprise application deployment.  I’ve seen too many implementations that have gone wrong or ended up simply re-creating the information mess that already existed in the organization.

So let me outline the resources required for ensuring success of your SharePoint implementation.   It is important to note that these resources do not simply go away once you have completed phase I of your global deployment.   Each one will be required for ongoing governance of operations and continued solutions development and support of business needs:

Program/Project Manager – an individual who not only knows how to manage IT projects, but also understand ECM, information architecture, software and solutions development, IT infrastructure, etc…   They don’t have to know how to write code or know SharePoint administration hands on.  They do need to have some “technical acumen” but they also need to evangelize the solutions to both end users and senior executives.  They need to know how manage and govern an application like SharePoint and have discussions about backups,restores, failover, disaster recovery, taxonomies, etc.  They also need to understand communications, collaboration, knowledge management, business process improvements, ECM, web 2.0 — all the capabilities that an organization might leverage with SharePoint.

Systems Analyst – Having the word “SharePoint” on this resource’s resume is just not required.  There are sooooo many GREAT system analyst resources that I have met who seem be stuck in their current role between IT and the Business.   Perhaps they’re in a Big 4 Consulting firm doing QA work on some legacy or ERP application or custom web development for some large Fortune 500 client, drafting business requirements documents, or working late nights with offshore development teams.  All of these individuals I’ve talked to seem disenchanted with their current role, see little career growth, are tired of their current technology focus, and are looking for the chance to work with an application that the sex-appeal of SharePoint.   It really doesn’t matter if these individuals know SharePoint or have seen it.   Let me repeat that: It really doesn’t matter if these individuals know SharePoint or have seen it. If they are experienced with any enterprise application, the skills are all transferable.   This role is so critical in SharePoint’s success because someone needs to work with the end users and business to understand their needs, map out the requirements and workflows, wireframe site designs, get hands with SharePoint Designer and do light customization and design of sites, and provide QA.  However, there is no reason why this resource needs to know how to write code.   They just need to interact with the business and developers ensure what is delivered to users has some level of quality and actually matches the requirements identified upfront in the project.   Lastly, a systems analyst is not someone who simply leaves once the initial deployment is completed.   This person will be needed for ongoing requests by the business to develop solutions on top of SharePoint.  So many companies have way too many internal processes that are paper based, inefficient, or handled over email….that a systems analyst resource will be busy for at least the next decade.

Solutions Architect and Jr Developers – Okay, so here are the resource who knows how to write code… .Net, visual studio, etc.   Maybe you offshore development and if you do, that’s fine.   However, you better have really really good system analysts and project managers to manage that development and provide the interface and QA to the business — especially if there are language barriers to manage.   Don’t expect these resources to know how to configure SharePoint, install it, or do any administration whatsoever.   However, it definitely helps if they do and can guide your organization in their deeper taxonomy planning, security, and high-level solution design.  Do expect they know the SharePoint object model, know how the performance impacts of developing point solutions on top of an enterprise infrastructure.

Information Architect – Expert in ECM and information architecture.  You’ll pay a premium for this resource, but it’s worth it.   Most deployments overlook the need for this person.  Maybe they have worked with other ECM applications like Filenet or Documentum.   Knowing SharePoint is useful, but not necessarily a must have.  If they have 10+ years experience with ECM applications, they can learn SharePoint’s model very quickly.   In fact, most Documentum or Filenet or Lotus consultants I know who have 15+ years experience all say the same thing — they’re doing exactly what they did 10-15 years ago — just at an enterprise scale and with SharePoint.

Systems Engineer / SharePoint Administrator – a Windows certified resource preferably.  Someone who knows how to install, configure, secure, troubleshoot IIS, OS, hardware, Virtual images, and network issues and in a global WAN or extended extranet environments.   When users can’t access SharePoint, you will not only need a really competent resource here — but you will be buying them drinks often!

Storage Engineer – your SAN or NAS experts who understand performance and storage considerations mostly around SQL databases unless you opt to store files outside of SQL.

DBA – SQL Server experts who should learn how SharePoint stores data and files, how to care and feed for it, limitations, and even options for storing files outside the database, etc…

So don’t understaff your SharePoint project.   The ROI is real and you’re making a mistake if you think you can offshore everything or pay a junior resource $40 or $50/hour onshore.    While some of these roles might be filled by a single person, you will likely pay more for someone who can wear many hats — and you should pay more for 1 person who addresses multiple needs (that normally would be addressed by multiple resources).   In this world, you get what you pay for….so don’t risk an information mess in your SharePoint deployment.   Get the right resource with the right skills for the right job….and yes, I’m available if you need help!  🙂

Share/Bookmark

 

July 28, 2010

Ultimate Guide to SharePoint Governance – download the outline now.



Share/Bookmark

July 28, 2010

Top 5 Reasons Why Strategic Initiatives Fail and a Way to Make Success Visible


Great article by a colleague of mine….published in Greater Charlotte Biz.   SharePoint provides the enabling capabilities to implement Executive Dashboards.

Share/Bookmark

http://www.greatercharlottebiz.com/article.asp?id=1069

We have all found ourselves, at one time or another, lamenting the “what ifs” after a great new strategic initiative comes charging out of the gates only to lose momentum and eventually fall into a ditch dying a slow quiet death. It happens in every company. The interesting part is it happens less frequently in some companies than in others. Do they avoid or minimize the pursuit of new initiatives? Do they take some magical approach to driving initiatives?     In these increasingly tough economic times, companies are not afforded the luxury of avoiding new initiatives. They are either getting better or they are falling behind, so the answer is obviously the approach they’re taking. Let’s take a quick look at the top 5 reasons why strategic initiatives fail and what companies can do to help keep initiatives out of the ditch. According to a recent study performed by Industry Week, the top 5 factors that are common elements of a failed initiative are:1. Strategy is not clearly communicated to the stakeholders 

2. Lack of support by key leaders in the organization

3. Decision-makers do not understand the relevance or are unable to measure progress

4. Lack of impact on employee compensation

5. Technology needed for implementation is not available

It comes as no surprise that these items will spell doom for most any initiative. It doesn’t have to be all of the items together either. A single setback in any one of these areas can knock an initiative right off of its tracks. If you are going through the efforts of researching, funding and implementing a new initiative, you certainly want to put a system in place to help ensure its success.

An excellent tool to use is called Dashboarding. Dashboarding is taking key metrics associated with your strategic initiative and displaying them in easily digested information. With Dashboarding you are taken through the process of identifying metrics that quantify success.

If you had to narrow down the Key Operating Indicators around the initiative to a handful, what would they be?  Now let’s put them in an easy to read and understand format that will be visible to everyone. As this dashboard is updated and distributed on a regular basis it keeps the initiative fresh and allows you to measure your success on an ongoing basis. In a word, it is POWERFUL!

In summary, continue to roll out great new initiatives as they are needed to insure your companies continued growth and success. Just remember, using Dashboarding as a tool to avoid the common elements of “initiative failure” will keep you out of the ditch and headed straight to the bank.


July 25, 2010

Seven Tips for Managing Projects on SharePoint


Download the full presentation on slideshare…. And please feel free to comment and share your own tips for managing projects using SharePoint.

This slideshow requires JavaScript.

 


Share/Bookmark

July 21, 2010

My recent presentation on Managing Projects on SharePoint is available…


Includes PM 101, Tips for Project Managers, Project Management Dashboards, and Enterprise Portfolio/Project Mgt with SharePoint 2010

View more presentations from Rich Blank.

 


Share/Bookmark

July 14, 2010

Does SharePoint Cause Information Management Problems?


Does-SharePoint-Cause-Information-Management-Problems?   Interesting blog post and discussion….my thoughts are below….

SharePoint as an application should provide better capabilities around administration AND information governance. 2010 is better but more out of the box functionality is needed.  As a result, organizations need to spend the additional money on 3rd party solutions for admin/security/governance — which, in my opinion, is a necessity, not a “nice-to-have”. However, tight times and tight budgets haven’t helped the situation. As a result we see alot of out of the box vanilla SharePoint deployments whose main use is a glorified fileshare. While that hasn’t been a bad thing — the simple fact that users can easily share documents (vs emailing them) has created a “Shareplosion” in many organizations — which further adds to the problem. Combine all that with a lack of information architecture, lack of internal marketing and little if any end user education— you have an “information mess”.

Perhaps AIIM might consider rethinking the term “information management” and rebrand it as “Information Governance”.  Maybe IT will spend more time and/or money on planning SharePoint with the right governance.  Good governance will empower users, make them more productive, help them find information better, and allow the business to create solutions that actually improve project management, collaboration, & business processes — way beyond simple sharing of documents.  Governance is all about — user adoption and empowerment being a direct correlation to IT’s ability to administer, govern, deploy, and support a stable application.  Governance is about BALANCE — balancing IT control against user empowerment to ensure security and foster adoption. And it’s not just “governance of the application” — it’s also about governance of the information.

The unfortunate thing is that governance often gets pushed aside in favor of other priorities….and I do understand why the subject is often ignored at many organizations.   It’s been several weeks since I started to post my formula for successful governance of SharePoint — and I’ve gotten sidetracked again with my own priorities….time to continue my discussion on governance..

 


Share/Bookmark

July 14, 2010

CIO Mindset


Found a great PPT from Gartner regarding the CIO Mindset….In particular, it mentions the top 10 things CIO’s want to spend money on.  These include (but not limited to) the cloud, governance, cost optimization, PMO, process improvements, and unified communications & collaboration……

http://www.gartner.com/it/content/1368300/1368385/june_22_the_cio_mindset_jbeck.pdf

Seems like SharePoint fits in well to what CIO’s are thinking about…..

Tags: