The document outlines the agenda for SharePoint Saturday in Virginia Beach on January 11, 2014, featuring various sessions and discussions about SharePoint project failures. It highlights the different meanings of project failure, common issues encountered, and emphasizes the importance of proper requirements documentation to prevent such failures. Key considerations include stakeholder involvement, technical dependencies, and the need for clear communication and understanding among project participants.

1. Stop SharePoint Project Failure;
Create Real Requirements
SharePoint Saturday Virginia Beach
January, 2014
Matthew J.
Bailey

2. Platinum Sponsors
Welcome to
SharePoint
Saturday
Virginia Beach
Jan 11, 2014
7:30 - 8:30 – Registration (Lobby)
Breakfast (Sponsor Hall)
8:30 - 8:45 - Welcome
9:00 - 10:15 – 1st Sessions
10:30 - 11:45 – 2nd Sessions
11:45 - 12:30 – Lunch (Sponsor Hall)
12:30 - 1:45 - 3rd Sessions
2:00 - 3:15 – 4th Sessions
3:30 - 4:45 – 5th Sessions
5:00 - 5:30 - Closing & Giveaways
Gold Sponsors
Silver Sponsors

3. I consider myself a “SharePoint All-Rounder”. My job tasks vary from
Administration, Development, Training, Analyst, UAT and Project Management.
My job changes daily based on the crazy life of an IT fellow in corporate America,
but it keeps things interesting!
If I don‟t know an answer to one of your questions, I will try to find out or point
you in the right direction!
SharePoint Business Analyst &
IT Project Manager
JDSU
Matthew J. Bailey, MCTS

4. What is Project Failure?
It means different things to
different people.






The product did not finish or launch at all / abandoned
The project finished but did not deploy
The project finished but not as promised or expected
The project finished and deployed but unexpected issues occur later
The project deployed, according to requirements, but no one used it

5. SharePoint Project Failures Quotes
What u talkin‟ bout Willis?




“It was so slow we couldn‟t use it.”
“We spent over 1 million dollars on it and it still doesn‟t do what we
wanted it to.”
“The project finished and deployed but unexpected issues occurred
later.”
“The project deployed, according to requirements, but no one used
it.”

6. SharePoint Project Failures What Really Happened
I be talkin‟ „bout this!




“It was so slow we couldn‟t use it”

“No one did a demo first” , “it has been a constant add-on of one project on top of
another coded poorly”, “so many people have worked on it, consultants, employee
turnover, etc”, “the sales person showed me a demo so I know it should work”, “I read it
on the internet so it must be true”, “the server infrastructure could not support it but no
one checked that first”, “it had 3rd party black box dependencies we can’t troubleshoot”
“We spent over 1 million dollars on it and it still doesn‟t do what we wanted it to”

“The right people were not involved in the design or are no longer here”, “someone
promised the moon and delivered an asteroid”, “miscommunication”, “requirements were
not very specific”, “people conveniently forget, especially when they made a mistake”
The project finished and deployed but unexpected issues occur later

“who would be managing later was not considered”, “employee turnover”, “long term
usage and data size was not considered”, “maintenance is not being performed”,
“uncontrollable issue such as my home internet service to my company’s VPN that is slow“
The project deployed, according to requirements, but no one used it
 “user design was not considered”, “the users of this were not consulted”

7. The “Risk” Factor


















Lack of knowledge of everything that has occurred in the
environment since it was implemented and/or lack of
SharePoint knowledge
3rd Party Tool Integration / Dependency on Other Items
Specialty coding / little documentation / hard to find a knowledgeable
resource
Lots of InfoPath (troubleshooting, slowness and instability)
Adding to an existing highly complex environment that you did not
build
Complex workflows
Lots of SharePoint Designer
Insufficient hardware (need to do research for what is sufficient)
Insufficient architecture / configuration
Trying something unknown without creating a thorough, real demo
3rd Party Dependency
Term Store / Taxonomy / Metadata Complexity
Multiple Languages
Different environments / keeping in sync / content deployment
Custom page layouts
Javascript files / jQuery version incompatibilities
Existing solution files / .dlls that need to be changed
Needing to code something that requires special permissions

8. Warning, success can be hard work
Our requirements / design
documents should include:
!


9. Requirements Documentation
Our requirements / design
documents should include:

 Scopes
 Assumptions
 Risks / Concerns / Unknowns
 Dependencies
 Audience
 Responsible Parties (even if unknown)
* NOTE: Requirements documents can vary from company to company.
These are guidelines not a mandated format that must be followed.

10. How we thought the project should go
We haven‟t realized it yet,
but it is going show up
later…




Performance
3rd Party Tool Integration / Dependency on Other Items
Hardware / Infrastructure Issues
Choosing poor development methods / lack of experience

11. How the project ended up going…

12. How could we have prevented
this?
Scope
•
•
•
•
How the user will interact to complete this process
What the finished result will be
What the expected level of effort will be
Budget
•
•
•
•
“ Oh, well we have text in CEWP and typed on the page.“
“ Understanding what SharePoint can/can’t do & how hard it is to do “
“ page should copy over any text we put on it. “
“ I know you told me that wasn't possible 3 times, but I am going to ask again and then ask
someone else on the team because I really want it. “
“It doesn’t have the wording I want “
“Oh, we have a bunch of custom web parts on the pages. They don't seem to be copying over to
some sites.”
•
•

13. How could we have prevented
this?
Audience (stakeholders)
• IT / Administrators / Infrastructure / Architecture
• End users / Other developers/project teams (not directly on this
project)
• Past parties involved with project (if needed)
• Change Management
• Managers (related or ones whose actions could put a stop to
everything)
• Project Managers & Project Developers
•
•
•
•
•
“Wait! We have a huge company acquisition coming and everything has to stop until we make
changes for that. “
“ Yeah, just send me an email and I'll do that (I'm still waiting...) “
“ Who are you? “
“ Others agenda / needto control / be right, etc. “
“ Oh, I didn't know anything about this project you were working on. We were working on
something that might affect this. “

14. How could we have prevented
this?
Dependencies
•
•
•
•
•
Ability to perform our job function / do what we need to
Ensure other items we need function properly now
Ensure we have access to what we need
Budget
Skilled SharePoint resources
•
“We are developing on a desktop configured with different versions of SharePoint vs. your
enterprise server configuration. Your Page Layouts on your test server are broken. “
“ Well, we have different page layouts that we use but it should work for all of them regardless of
which one we use. “
“ How come these CQWP parts aren't showing on some of the site pages? Yeah, they are all looking
up different to list items based on different metadata terms, most of which don't exist so they
would apply to the new page on the other site. “
•
•

15. How could we have prevented
this?
Assumptions
• Governance stating what is allowed to be done/used in this
environment
• Bugs - Known
• Properly configured well performing infrastructure
•
•
•
•
“What am I allowed to do”
“We have to present this to Change Management now. Oh, you don't feel comfortable with
manually copying .dll files to 9 servers due to our load balanced environment?”
“Why is this workflow sooooo slow?”
“ What do you mean I'm not allowed to use SPD on the test server, why is it disabled? You didn't
tell us how we could build it. SPD is disabled for security reasons, why would you need it? “

16. How could we have prevented
this?
Risks / Unknowns
• Company initiatives
• Project participant turnover
• Project history
•
•
•
•
•
“ Effective immediately, we will be streamlining the organization and the following personnel
changes will be made... “
“ We have to do a restore on a server so your project is delayed. “
“ yyy isn't available, you will now be contacting zzz “
“ xxx isn't available, you will now be contacting yyy “
“ History “

17. How could we have prevented
this?
Responsible Parties
•
•
•
•
Company initiatives
Project participant turnover
Project history
Participant commitment
•
•
•
“Yeah, just send me an email and I'll do that (I'm still waiting...)“
“I have too much to do (a.k.a., surfing the internet) and can't test this, can you ask someone else? “
“I thought we had agreed on a list of defects with this project, why have some disappeared from
the bug list“

18. It‟s a fine line to walk…
Depending on your role, you
may not be at liberty to
address some topics

 If you are in IT, you don‟t want to look incompetent, yet lack of disclosure creates an
environment for rumors to be created and spread.
 If you are a consultant, there is a challenge between knowing you need the work to survive
yet not being dishonest or taking on more than you can handle.
 If you are in management, you may not be able to disclose items such as budget,
employee turn over, company/IT direction, etc.
 If you are selling the 3rd party product, it is hard to know everything about a potential
customer‟s systems and needs, yet bringing it up could eliminate the product from being
considered.

19. More Ideas to create scope…
What can assist us with
project success even more?
 Pictures / Video
 Technically specific SharePoint items
 Diagrams


20. Step 1 – What we know
What are we sure of and is
ready for a final
confirmation?
!
! We know we are building a workflow
! We know who some of the people involved are
! We know there will be a budget and IT related people involved
! We know there will probably be a timeline

21. Step 2 – What we know we don‟t
know
What are we not sure of but
know it?
?
? Who in IT will be helping us
? Who specifically will the developers be
? What parts of SharePoint technology are we going to be using
? What are our restrictions regarding coding / implementation
? Who could be the other stakeholders in this

22. Step 3 – What we don‟t know we
don‟t know
We haven‟t realized it yet,
but it is going show up
later…
•
•
•
•
Bugs that will surface
Company initiatives changing
Participant / people turnover
People‟s agenda

23. Example – Poor Requirements
The system will use a workflow to copy a page to 8 other sites based on
a user selection.

24. Example – Better
Requirements
The system will use a workflow to copy a page to 8 other sites using the publishing workflow
feature of SharePoint and custom code. The originating page must be checked in and
published for this button to function properly. Versioning will be disabled to ensure consistency
between the pages across sites and avoid different sites having restored pages that are
different versions. After clicking a button in the ribbon, on the page that the user will be
copying, the system will present a form with 8 site options to the user. Any number and/or
combination of the 8 options may be selected by the user. There will be a button on the bottom
of the form that, when clicked upon, will submit the form and begin the publishing process
within SharePoint.
Based upon which of the previous 8 options were chosen by the user on the form, the system
will copy the originating page to each of the selected sites upon submission. Any content on
the page, including pictures or links will copied “as-is” and relative links should be used to
ensure pictures display properly. The copied pages will appear in the sites selected by the user
nearly immediately, using the same page layout with the same web parts and master pages
and display in Published status. The workflow will only function to create new pages and will
not update content after the initial run. Should a user use the copy feature more than once for
a page that has already been copied to other site, the recipient pages will be overwritten with
the current content of the originating page. Thus, changes to the pages that were copied are
not suggested if they may be overwritten over again in the future.

25. Diagrams can help, or at least confuse your stakeholders
enough to make them stop and think….
Our requirements / design
documents should include:
 Scopes
 Assumptions
 Risks
 Dependencies


26. A picture is worth a thousand words hours of work

27. SharePoint Technical Considerations (1)
Are we allowed to deploy full trust solutions?
Would be good to know if we can use all of the SharePoint functionality or not
upfront.
Are we depending on an AD authentication from another
location?
Have the users been made aware that there can be slowness or failure due to
AD being down on the verification side?
Are we dependent on a web service/data cloud service from
another system?
Has this service been tested / researched for reliability?
Are we allowed / will we need to run code with elevated
privledges?
Has research been done to verify that you must use this method, if it alright to
use it at this company?
Are we allowed to deploy code to the GAC?
Did we ask if we can create custom .dll files and must they be bundled in a
.wsp for deployment?
Who manages the term store? Programming against it can have challenges.
There were known bugs with renaming terms in the Hidden Taxonomy List
prior to SP1 for SP2010. If programming against it, how are you programming
Are we dependent on or using a complex taxonomy / term store? to access the data.
Are we dependent on data that is not always fresh, such as a
search index or an import job?
Anything dependent on the User Profile Service?
Are we familiar with the search topology, can it support robust searching? How
frequently are the indexes crawling and will full or incremental crawls be used?
Do we know how often this runs and what it is importing?
Are there items such as cache settings or security you do not
know about that will create issues?
Have we checked if there is any site level caching, site collection level caching,
server level caching or load-balanced / failover issues that could make us think
twice on how we program?
Do we have proper test / stage / prod environments to properly
develop test on (whether it be internal or working another party
who is doing the development for you)?
Do we have proper, completely similar environments set up to develop, test
and deploy on? Was a good deal of time spent comparing the environments to
make sure they are similar (i.e., C.U., SP numbers, features enabled, search set
up same)?

28. SharePoint Technical Considerations (2)
Are we allowed to run PowerShell scripts?
Is there anything in this project that is going to require data clean up, changes to
existing items, special configurations or other items that you will need PowerShell for?
Are we aware of architecture / power of architecture?
Although this can be difficult to gauge, do we at least know how many servers, with
what types of hard drives, CPUs, memory & network connections are in this puzzle?
Which features / services are enabled on which servers? Can what I am implementing
handle the traffic, processes or coding?
Are we aware of complexity of previous solutions / coding you are
walking into that is messy?
Do we know the history of this project? Have several people already worked on it and
left it in a shambles? Is there documentation or can we get a hold of someone who
worked on it? Are there end users available who can explain what it is supposed to be
doing?
Will we need to/ are we allowed to create custom Timer Jobs /
schedules windows tasks?
If you are start to require complex coding, will you be allowed to create these types of
features on the servers? Will the server admins allow it?
If you cannot increase the frequency of the timer jobs, do the users at least know that
Will we rely on scheduled tasks or timer jobs that do not run frequently in some cases the time delay so they do not think something is broken as it "appears to
enough?
work one day and not the next"
Can I give the right permissions to users of your application that are
need to use it?
Have we designated which role needs to accomplish which tasks in which areas of
SharePoint (i.e. there are sites they need Owner access to but they are a Contributor
everywhere else, do we need to create custom permission levels)
Will I need / can I use some "fancy" security authentications such as
claims/secure store/FBA, etc?
Is IT alright with doing this? Has the person doing it completed something similar in
the past to troubleshoot the complexities of it?
Will we be doing client side/browser dependent application coding and User experience such as streaming media from 3rd party video player, mobile,
can't control the clients browser or device?
responsive design is a potential UX risk.
Will we need custom web parts?
Are there already web parts to do this? Can a 3rd party web part be used instead
(risks)?
Will be using using some codeplex / open source unsupported code?
Has there been a lot of testing done to ensure the usability of this? Is it continually
update or supported? Is there any other information on the internet about it or do you
know anyone who has used it?

29. SharePoint Technical Considerations (3)
Are we dependant on an API that could change?
jQuery and version changes, different items needing different versions. Other
products API that could change (i.e. video streaming service other .js libraries,
java, ODBC)
Are we dependant on 3rd party applications running on top of
SharePoint that are like a "black box"?
Is there a product such as a workflow or data integration product from a 3rd
party involved in this project? If so, are you familiar with how it works or is
there little ability to see
Is there a code vault/TFS scenario in place? Is there ongoing discussion with all
Are there multiple people working on a project and there is code developers involved? Are others deploying code in between times you are
overlap or overwrite?
introducing new conflicts?
Are we sure of data retrieval formats / availability?
Are you aware of how the data in SharePoint/SQL is stored? If using InfoPath,
are you aware of how some of the format of the data is returned?
Are we familiar with applicable known bugs / patches ?
A quick glance to the known bugs site for SharePoint can give some guidance
Will we be able to access ULS logs to troubleshoot on production Will you have access to the ULS/Server logs to troubleshoot, how long are
servers?
they being kept for, are there backups created if something goes wrong,
Is existing lack of governance going to create issues?
Are we using InfoPath?
data formats, different types of columns, data spread across different
sites/collections/web applications
Are we using SharePoint Designer Workflows?
Are using a great deal of InfoPath, is it mixed in with Content Deployment
Do you understand the level of complexity of the workflows going forward
and currently? Can SPD workflows support this, would VS workflows be
better?
Might we might be upgrading soon?
There are a great number of changes in SharePoint 2013 that could affect how
you do many things

30. Final Thoughts…
What can assist us with
project success even more?

 Letting Go: What can you control, what can you not
 Do your best, keep notes from each lesson you learn for future projects
 Take the time, even though it may not be enjoyable, to do more work upfront
 Get commitment and sign off from others
 Don’t give up! (unless you just got a way better job offer of course)

31. Feel free to connect:
@matthewjbailey1
http://www.matthewjbailey.com
http://www.linkedin.com/in/matthewjbailey1
sharepointmatthew@gmail.com
Download my slides and get started at:
http://bit.ly/1eKU185