Posts tagged ‘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:

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.

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!  🙂



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.



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.



June 15, 2010

10 Questions to Ask the “IT Guy”…

Good article I found…

If you run a company, you’re probably used to your “IT Guy” telling you that you need to do this and that.  It seems like there’s always an opportunity to upgrade, update, replace, implement, and install technology.  It could be new hardware, new software, new accessories, a new phone, a new server, new cabling…a new widget even…it could be anything….

How do you know when it’s just the IT guy finding “something to do” and when it’s really something that makes sense and will add value to the organization? After years of being in the IT industry and working with business leaders, we’ve come up with a “reasonability” test of 10 questions that can help establish if something is really worth doing and, if it’s worth doing, how it should be done.  The next time your “IT guy” (or anyone actually) suggests something, ask these questions:

1.    What is the business justification for implementing it? If there is not a specific business justification for doing it, there’s a good chance it’s not worth doing.  Will it increase revenues?  Will it reduce costs either over the short term or long term?  Can it improve the company’s competitive position in the marketplace?  Will it improve employee morale?  What is the business reason for doing it?
2.    Who is the one person who will be responsible for the success of the project? Many times your IT Manager will encourage the organization to implement some new technology, but then the success of the project will depend on other departments and/or users in the organization.  Who will be responsible?  Does that person have the authority to see the project through to its success?  Responsibility without authority doesn’t work.
3.    Define “success” for the implementation?  What will it look like?  What specific results will we see? Make sure everyone in the organization is on the same page when defining success.  Is the “go live” date part of success?  Are certain functions required?  Are certain reports required?  Have a clearly set definition of success.
4.    How much will it cost?  Upfront?  Ongoing (monthly, annually)? What something costs is never a simple thing.  There’s the initial cost.  There’s the ongoing cost.  There might be annual maintenance.  There might be annual support.  There might be future phase costs.  Make sure you get the number that includes EVERYTHING.
5.    Who will be responsible for the cost?  What happens if it goes over? Is the IT guy taking responsibility for the cost?   What are the repercussions if the cost turns out to be different?
6.    How long has it been on the market? Ask how long its been on the market.  Is this a new technology or an old technology?  If it’s an upgrade, will you be the first company to install the upgrade, or has the upgrade been out on the market for a while?    Our approach is generally to not be the first user of anything, whether it’s an upgrade or a new product.  We like to see products get at least six to 12 months of legs before recommending that our clients go forward, unless there’s some compelling business reason to ignore this rule.
7.    Can you get at least three references? Are there references for what’s being recommended?  While it’s great to spend the time calling the references, it’s even more important to know that references can be provided.  If someone can’t provide at least three references, the product or upgrade is likely suspect.
8.    Will there be downtime associated with the installation? Really.  Will the implementation happen over a weekend or during the week?   What happens if the installation fails?  Can you go back?
9.    Who do our employees contact when there is an issue?  How do they contact them?  Who is taking responsibility for support?  Is it an internal resource or an external resource?  What are the expectations for support?  24×7?   9-5?   How much downtime will you allow if the new technology causes downtime?  Is there a backup plan?
10.    Will training be required?  Who will do this?  How long will it take?

A lot of times training is taken for granted, or the need for training is minimized.  Don’t.  Training is the secret weapon of technology.  If you train your people in using technology, experience has proven that they are significantly more motivated in using the technology successfully.

May 19, 2010

Top Traits of a Good PM – PMI Metrolina May Meeting

I attended the local PMI chapter meeting last night.   NouvEON had a strong presence which was great to see since they sponsored the meeting last night.  I also took some notes on the speaker — of course I didn’t write his name down.   He began by outlining the characteristics that make up a good Project Manager to “Win at the PM Game” – the subject of his presentation:
1. being assertive & an extrovert
2. communication skills
3. ability to manage sponsors
4. adding value
5. presentation matters
6. ROI
There’s probably more but those are what I captured and I’d be interested in hearing other people’s ideas on what makes up a good PM.  The bulk his presentation focused on communication as 90% of what a PM does….which flowed into building trust, relationships, listening to voice of customer, knowing the audience, negotiation, defining goals/objectives, etc…   Dr Phil he was not, but he raised some good points about communcation.
One of the most important things relating to communcation was building a relationship and trust — which can be achieved through openness and our ability to communicate across time & space.   While he mentioned email, oral, and written communication — no where did he mention collaboration tools like SharePoint — which in my opinion can help achieve trust and openness and provide visibility of information.   A woman from the audience even asked about how we can build relationships & trust in virtual teams — which we ALL work in today.   The speaker really didn’t have a good response.   I almost jumped in to respond and wanted to argue that email actually is a bad way to have discussions and build relationships.  Many times, people write TOO much in an email and immediately we dismiss them or ignore their communication — which doesn’t help the overall relationship.   With email you lose context, miss discussions & important information, etc, etc….   The “message” and the meaning and actionable items often get lost in email.    Of course if we use a technology like SharePoint correctly, it can be a very powerful tool for communication, building trust, providing transparency & visibility for any team — virtually or locally in the same building (let’s face it, we often times email people down the hall or on another floor!)
Anyway, the last takewaways from the speaker were the following:
The speaker’s formula to breakdown communication and relationships:
-Simplicity + Lack of Communication – Trust – R – Credibility x Adaptability
(Unfortunately I can’t remember what the R was for).
And one participant in the audience mentioned Steven Covey’s new book “The Speed of Trust” which talks about all of this.  Perhaps the speaker read Mr Coveys book and based his presentation on it without citing him! 🙂    When that was mentioned I thought of another book I read when I first started as a consultant: “Managing the Professional Services Firm“.  There were 3 things that I remember to this day that help me as a consultant & PM:
1. Confidence
2. Competence
3. Credibility
I guess we could add a 4th C and include “Communication”….


September 9, 2009

3 Keys to a Successful SharePoint Deployment

Recently, someone asked me what makes a successful SharePoint deployment.   I responded with the following:  Platform, Governance, and Marketing.

1. Platform: The first part involves a stable platform.   Focus on the infrastructure, hardware, availability, performance, backups, etc..  Anything relating to making the environment stable.

2. Governance: all things operational and support focused.

3. Finally marketing: you need to market the application to end users, do demos, create proof of concepts, and show people what’s possible.

Follow me on Twitter…

May 14, 2008

Lessons Learned from eRoom …

Once you start to use eRoom, it’s very hard to work any other way.  I have used Sharepoint, Lotus Quickr, and of course the old standard email to manage projects.   And I’m a little biased towards eRoom even to this day.    Now in full disclosure I used to work for eRoom(which became Documentum then EMC) since 1999 and I have seen the cult-like following its users have.   From early adopters like the Wharton Business School to Deloitte and Ford….. I’ve been inside too many customers to count across the globe.   

SharePoint is definitely getting better and has a developer community which will no doubt help drive it’s ultimate dominance over the market.  eRoom was definitely bleeding edge for it time and there is a lesson to be learned from it.   And the lesson is that the designers and product managers of eRoom listened to customers and listened to the people in the field who made this technology work.   As a result, eRoom was rapidly deployed and easily adopted by end users.   10 things that made eRoom implemented and accepted so quickly are:

1. Ease of setup and adoption.  eRoom was designed to be easy from the start — from install to room creation — the designers of this product recognized eRoom is a productivity tool for knowledge workers and adoption is the most important thing to consider with this type of technology.   

2.  The eRoom database feature.  Again easy — simple wizard to create a database inside a room.  If you ever used Lotus Notes, there is NO developer required here.   From a simple contact list to Q&As, to part or inventory lists to document libraries — this is probably the most used and most powerful feature inside eRoom.    Highly customizable, highly secure, AND the ability to nest any other eRoom object inside a row.  And accessible via API/XML makes this a POWERFUL feature.

3. Nesting.   This is simply smart design.  It’s much more than a folder or file inside a folder….it’s ANY object inside ANY other object.   Again, this parent-child relationship makes it secure and easy to see what belongs where — keeping everything organized within whatever “context” you desire.   This also helps you secure the workspace.  And if you are anal and like to be organized — so you can easily find things later — you’ll like eRoom’s ability to nest objects too.    

4. Communities.  Again – ahead of its time.   Tight integration with multiple LDAP vendors and native eRoom membership — this community model came out in like 2001? — before the Web 2.0 craze made this a more popular buzzword.   And one of the most critical things for these types of applications is the ability to get people quick, easy, and secure access.  We’re NOT talking about openness here.  eRoom communities help you secure your workspaces, allow you to do segment the user population, and prevent “potential” access to eRooms within a community (that is if you setup communities the right way). 

5. Flexible interface.  What I mean by this is eRoom is like a blank canvas for me to paint.  As a project manager or person “coordinating” the room — I can design the room layout however I want — and again it’s EASY!   Folders, databases, room settings for announcements or status… so so so smart!!    Other competing apps — sorry, they just don’t compare (try and mess with Sharepoint interface as a non-techy…not so easy).   eRoom is flexible because it is not as structured in its taxonomy like a Documentum content server for example.  While Documentum is powerful in its own right for heavy duty content/document management — eRoom removes alot of that complexity and provides simple document management & controls.   This is yet another example where eRoom was ahead of its time — allowing users to create their own “folksonomy” using eRoom objects like folders, databases, notes, discussions, etc…   Tagging can be done with custom fields, but not many customers have exposed that feature which is ashame.  

6. Supportability — okay, every software application has it’s problems.   Having done some technical support in my former life, it’s like seeing someone naked — all the flaws, cellulite, wrinkles, etc..   And while eRoom has some sex appeal, the app is no exception 🙂   However, most sys admins setup eRoom and let it run.  The learning curve for admins is low and the biggest issue is probably scalability – not because it doesn’t scale — you just have to scale it correctly.   So don’t take the easy supportability for granted and pay attention to both hardware and application limitations as you grow your deployment — and this will make supportability easier.   Let’s face it — growth isn’t such a bad problem to have….

7. Security.   Ahh .. the global economy and new buzzwords like open collaboration, peace, love and sharing and caring — well that was great in the 1960’s, but this is 2008 — and the real buzzword people should be saying is SECURE COLLABORATION!!!!    And eRoom is by far the most secure collaboration tool out there.  Why?  Because again designers listened to customers early on and designed it that way.  Okay, one could argue “it runs on microsoft IIS”.   Sure, like 90% of the world, we are at the mercy of Mr. Softy.  But there’s a reason why law firms, professional service firms, pharma firms, energy companies and just about every industry out there uses eRoom — and that’s because they can use it on the public internet, put highly sensitive documents and project / product information in an eRoom, and TRUST that they can securely collaborate with their extended enterprise or clients.  And eRoom 7.4 even integrates rights management around documents to make it even more secure. 

8. Document Management.  Uploading documents into eRoom is easy.  3 step process: Add file, browse, okay – you’re done.  Of course with the plugin, you drag & drop from your desktop to the browser — doesn’t get easier than that.   In an eRoom, double click on the file to read or edit it — once again easy.   You want to do some lightweight content management for your line of business or department or project or business process?  Create an eRoom database with an “attachment field”.  Keep things neat, organized, and again easy to search.   It’s all about context!   Sure, Sharepoint has a doc library — but try to nest a discussion thread under each row… not so easy,

9. Project Management.  By far the biggest use of eroom is to manage projects.  Everyone works off the same page…no emailing documents back and forth, version control, etc..  And as I mentioned earlier, I like the flexibility of painting my eRoom canvas to match my project.  Easy to add a custom banner graphic, a project plan feature, easy status reporting, easy to manage issues/Q&A/tasks/scope changes, an approval process database for change requests — simple basic project management stuff most people find painful to manage in Word or Excel.   Even better, I can setup an alert email that is sent to me immediately if someone updates something I think is important.  Or I can just opt to get a nightly email summary of changes in an eroom.  This push communications makes my life easier as a project manager.

10. Customizability.  You can build so much cool stuff on top of eRoom or push / pull data to/from an eRoom.   And you can brand eRoom to make it your own too.  You want to bring visibility into who is working on what task and when it’s due across all eRooms — and the dashboard feature doesn’t quite cut it?    It’s easy to add a custom web page that allows you to slice and dice data within the eRoom tree structure and bring transparency and accountability to the work people are doing.   You want to see more robust reporting on an eRoom database?  Easy to build and secure API/xml access.    You want to pull ERP data into an eRoom to bring visibility to it there within a “secure context” — you can do it easily.