The SharePoint Project

This week I attended the Australian SharePoint Conference at the Hilton Hotel in Sydney. I've decided this is the last year I will be an attendee. Next year, I plan on presenting.

I am currently managing my fourth "SharePoint project". This is somewhat of a misleading proposition. As a former application developer and business analyst, I have always tried to deliver based on business objectives. As a Project Manager, I need to understand why there is a "SharePoint Project."

What is a "SharePoint Project?" SharePoint is a platform. Thankfully, this is the main message out of the conference to those just beginning to dabble in the technology.  One session estimated, by a show of hands, that 40% of the room was on 2007, 40% on 2010 and the rest were "thinking about" going to SharePoint. This message is for that last 20%.

By the time I'm hired as the Project Manager, the platform has already been "installed." Infrastructure guys (and I love you) have found SharePoint on the Windows server and "turned it on". Now to tell someone how to use it!

Voila! The SharePoint project is born. Some sites get created; the webmaster thinks it would make a great intranet; the document/records lady notices you can tag stuff with metadata. The CIO throws a barely six-figure sum at the budget and asks the Infrastructure guys to do this in their spare time.

No wonder so many people hate SharePoint. It's treated like Infrastructure.

Paul Culmsee, in his Day2 keynote speech, noted that things like installing servers are simple. You plug it in and it works. It's basically the same every time. Sure you have to hook up dummaflobbers and whatsits, but servers are interchangeable for many purposes. And infrastructure guys are great at knowing all this.

Things like Exchange/ Outlook are little more complicated. You configure it based on requirements that are predictable. People want to get mail and send mail. The requirement and business objective is that the thing works. I don't have to ask anyone what "success" looks like.

SharePoint implementation, however, is complex or sometimes chaotic. The requirements are many. The Webmaster wants a good content management system; the Enterprise Architect wants good information architecture; the Records Manager needs a single source of truth. SharePoint has suddenly become the solution to everyone's problem.

But that's just it. It's a solution. You need a problem to solve. SharePoint can be configured and adapted to do just about anything, but you just don't know what that anything is yet. 

Mark Miller, the editor of EndUserSharePoint.com, is right in saying that business objectives should drive the use of the platform. If you're not careful, you could end up blow-drying your pizza, or microwaving your dog.

The platform needs to have a strategy, a reason to exist.  From the strategy, projects branded with the business purpose in mind can be launched. Each project - document management, intranet, business process workflow - should have its own business objectives and a determination made as to whether SharePoint is the right platform. 

Next year at the conference, I'd like to see less geeks and more business folks. Vendors should be inviting their contacts along to see how SharePoint can provide the platform for the solution.  I'd like to see Governance replaced by Strategy; Workflow Management replaced by Business Process Implementation; Site Branding replaced by Project Branding. Let's start using the term "SharePoint" in context as the middle-bit between Windows and the applications that run on it.

End Users can then be taught the Business Solution. And no one, other than the Infrastructure guys, should ever care that it's called SharePoint.

What would you like to learn about from a SharePoint conference?

When is AGILE not agile?

Late last year, Telstra, Australia's largest telecommunications company, introduced Agile development techniques to its IT software development project teams. The theory is that smaller, self-managed teams will create better software, quicker.

As a certified Project Manager with business analysis and development experience, I love the idea that deliverables can be parceled out to a small empowered team. Unfortunately, I have also been engaged to "rescue" or "re-discipline" some of these teams who have either failed to deliver a viable solution, or have exceeded the project budget without delivering. In my experience, many "Agile" IT shops are using it as an excuse to not have any governance or project management at all.

Still, I think there is an opportunity for Agile to create quick, sustainable and cost-effective solutions for business and IT. The Agile Manifesto was declared in 2001 by a group of technologists who were struggling to fight the tiered management bureaucracy to create effective solutions.

The first paragraph of the AGILE Manifesto Principles is:

"Our highest priority is to satisfy the customer through early and continuous delivery of valuable software."

A lot of emphasis is placed on "satisfy the customer" and "early and continuous delivery". But how do we define "valuable software?"

I pondered the Manifesto against my experience and came up with these Critical Success Factors for Agile Development.

CSF 1 - A succinct, defined problem

There is no doubt that a large problem such as "replace all legacy systems" cannot be Agile. Large problems require a big investment with commitment from a lot of people. Selecting small problems with tight solutions are key.  I've found that these work best for stand-alone web applications, or applications that collect or display data. Large implementations like ERPs and CRMs will never be agile, because you will never get a small enough base of knowledge, signoff, or commitment.

CSF 2 - A defined technical architecture

 "The best architectures, requirements, and designs emerge from self-organizing teams."

In this paragraph of the Manifesto, the term "architectures" must be defined. An application can only be efficiently managed if it conforms to the architecture investment of the organisation. For instance, if the shop builds all applications on Microsoft platforms, introducing a UNIX platform in the solution will not only delay the project, but increase on-going operational costs. Defined as "solution architecture," the team will create reusable code and objects that will make their lives easier as they add to the functionality of the software.

 

CSF 3 - Governance and measures

"The sponsors, developers, and users should be able to maintain a constant pace indefinitely." 

The Manifesto also ordains sponsors. This means that they will want progress reports. So before commissioning a team to solve the problem, we should determine how we will measure their success and report and approve their solution. Will we have an option to throw away the solution? How will we evaluate it before we spend additional money on additional functionality? How will we determine which functionality goes in which solution? At what point do we review the technical architecture and how information flows in the organisation?

"Working software is the primary measure of progress."

"Working software" should be defined as part of the problem definition. Is the solution designed for a single purpose or will the software be used for multiple problems?  How much functionality do we need before the software is considered "valuable?"

CSF 4 - Dedicated, empowered business users working with IT

 "Business people and developers must work together daily throughout the project"

Agile is not an IT methodology. It is a way for business people to solve their problem using the tool of technology. This requires a time investment of their most knowledgeable and trustworthy people. It means that only necessary staff should be on the team, and not political plants. If the "right" business people are not involved, then the software will not be valuable, because bureaucracy will again, takeover.
 

CSF 5 - Development and testing strategy and guidelines

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

Good developers are not always good designers or architects. Identifying constraints and boundaries for technical architecture and design gives teams a framework for their solution. Tools such as Microsoft Visual Studio allow developers rigour and flexibility. Enough of both should be included in the guidelines.

"Simplicity--the art of maximizing the amount of work not done--is essential."

The team should strive to build a solution that will allow for additional functionality and minimize re-work.  Testing guidelines should include testing by uninvolved team members. When business people get involved throughout, they start thinking "happy path" just like the developers. Define testing roles up front with the business. Consider user acceptance testing as training for the users.

"At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly" 

Guidelines should be reviewed at the end of each scrum and recommendations made on what to change. The goal should always be to improve quality and speed, within budget and costs. The "amount of work not done" extends to future work that will not need to be done, or a conscious decision to include the work in a later release. The challenge for the team is to leave tidy code that is maintainable, and not just by the person who wrote it.

CSF 6 - Experienced IT and business users team members

"Continuous attention to technical excellence and good design enhances agility."

Inexperienced team members cannot make informed decisions about excellence and good design. They will likely take the quick and happy path to solution development, creating solutions that are difficult to maintain, enhance and integrate with other solutions. Team members should also be aware of good business analysis and project management principles, especially budget and time requirements.

Team members must be multi-disciplined and collaborative. Egos should be kept in check, with the solution a priority.

There's no guarantee that your Agile project will be a success, but if these are defined up front for all Agile project, I'm backing that you will have a better chance of success.