Alfresco Share for Streamlining Project Management And Collaboration - Blue Fish Development Group
•Als PPT, PDF herunterladen•
4 gefällt mir•2,177 views
Full recorded webinar at http://www.alfresco.com/about/events/ondemand Blue Fish Development Group has been delivering Enterprise Content Management systems for over ten years. And when it comes to running their own business, they use Alfresco Share. Come see how Blue Fish uses Share to run their project operations, and learn how Share can be leveraged for your own collaboration needs. In this Webinar you will: -· See how Share can be used as a portal for managing agile software development; -· Witness the contrast between using Share and making do with a set of isolated a la cart solutions; -· Learn strategies for adapting Share to support unique business needs. For more information about Blue Fish, go to www.bluefishgroup.com.
![Webinar Overview ,[object Object],[object Object],[object Object],[object Object],[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Weitere ähnliche Inhalte
Mehr von Alfresco Software
Mehr von Alfresco Software (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
Alfresco Share for Streamlining Project Management And Collaboration - Blue Fish Development Group
- 1. Streamlining Project Management and Team Communication with Alfresco Share 3.2 August 25, 2009 Joshua Toub, General Manager Josh McJilton, Project Manager
- 6. An Hour in the Life of a Tech Lead… MS Project Google Sites Google Docs FogBugz Documentum Instant Messenger MS Excel MS Outlook MS Word Phone MS Outlook MS Outlook Documentum Documentum Documentum Instant Messenger Documentum Instant Messenger
Hinweis der Redaktion
- As a company focused on Enterprise Content Management, we think of our adoption of Share as an example of “eating our own fish food.” And in today’s webinar, we’d like to walk you through our Share implementation and show you how it helps us streamline our daily project tasks.
- We are a software consulting company focused on Enterprise Content Management. A lot of our business has been with larger companies, but we have also done a fare number of projects with smaller companies as well.
- We’ve been around for over ten years and all we do are ECM solutions. We have pretty recently become an Alfresco SI partner, and we’re super excited about working with them, the Alfresco community, and—of course!—the technology. And finally, we’re based in Sunny—and right now, very, very hot!—Austin, TX, but work with folks all over the world.
- To give you some context on why we turned to Share, let me give you a quick overview of how we traditionally operated projects. We typically follow an Agile development methodology involving Daily project standup meetings; Iterative development And so forth. For project management, we use what I like to call a “rigorous but adaptable” framework. Over the years, we’ve established many best practices, and have captured them inside a variety of project management artifacts, such as requirements templates, status reports templates, checklsits, and so on. However, because every project is unique in some way, we often find ourselves adapting these templates and processes to project needs. Also, in the vein of continuous improvement, we’re constantly evolving our templates and processes. I mention all this because it tends to create evergreen document templates, which can be a content management challenge. In support of these development and project management practices, our team members have traditionally needed to use a whole bunch of different tools. We use some tools that many of you are probably familiar with, like Microsoft Word, Excel, and Project… And we use some tools that you may not have heard of before, including: FogBugz, which we use for feature and issue tracking; Replicon, which we use for time reporting, Google Sites, which we had been using for project wikis, Google Docs, which we use for real-time document collaboration And of course we rely heavily on Email, Instant Messenger, and the Phone And more… And finally, we do an existing ECM system, and with lots of content and 100% adoption, it’s essential to our business. However, it operates completely standalone and isn’t integrated into our daily processes. There are a number of reasons for this: Customizing it to integrate with our other systems would take considerable effort, and then we’d have the challenge of keeping those customizations up to date with our evolving processes. It really doesn’t help us with collaboration And at the end of the day, it’s primarily used as a document archive.
- Now that you have some background, let’s take a look at how some of these tools are actually used. Let’s peek into a typical hour of a Blue Fish technical lead. At Blue Fish, technical leads are ultimately accountable for the technical success of our projects. They need to ensure that we are building the right things to solve our clients’ challenges, and they also need to ensure that we’re building them right. So, in addition to leading a team of consultants and developers, technical leads frequently communicate with our clients, and also collaborate with Project Managers to ensure projects stay on track. This multi-party-communication really requires a lot of back-and-forth between all of our project tools. OK. Let’s dive in… Let’s assume that our tech lead is just starting his or her day. The thing he or she is likely to do is to check on progress the team made in the last 24 hours. To check on team progress, our technical leads log in to Google to check our virtual whiteboard. We use these whiteboards to support plan and track daily tasks each team member is accountable for and to facilitate our daily standup meetings. We use a hosted Google spreadsheet because it seems to do a nice job at letting multiple people edit it at the same time. Now that our technical lead has briefed himself on the latest progress, he might turn to his email client to look for project-related emails. In this example, let’s assume that he gets an email with an attachment that contains revisions to a design document. The technical lead would then … open the document, and maybe make some edits or comments. How will the edits get back to the original sender? That’s right—with email. So the tech lead responds via email, attaching the design document, and most likely including some important feedback in the body of the email as well. Now let’s say that the technical lead is looking for the latest version of another project document—let’s say a requirements document. He wants to find the latest version received from the client. So first, the tech lead logs into our CM system, and navigates down to the project folder which should contain the document. Unfortunately, our tech lead finds that the latest version has not been checked in. SO, now he needs to hunt down the latest version. How might he do that? via IM… and when that doesn’t work, he might send an email… or he might find the team member responsible for the document and ask him or her for the latest version… After some time elapses, the tech lead gets his hands on the document. The first thing he does—because he has good content management hygiene—is to upload this latest version into the CMS. Then, to make sure that team members don’t lose track of the official version, he logs into the Wiki and posts a link to the document in the CMS. Now that the requirements document has been taken care of, our tech lead moves on to review the current issue status on the project. He logs into Fogbugz and selects the appropriate filters to look at the high-priority issues for his project. Now let’s say he seems something concerning, and decides that the Project Manager needs to be alerted… He contacts the project manager And they decide they need to review the overall project plan. SO, They log on to our Microsoft Project Server and review the plan… Upon reviewing the plan, they find that they need to verify some values in the latest project status report. SO… They log into the CMS, and Open the latest status report. They might then update the status report… … and check it back into the CMS… And as all this is wrapping up,… … our tech lead gets a call from the client, asking a question about a design document. … and the cycle… … repeats… Now, I hope that most of you don’t have experiences like this, but I bet a lot of you do. Not only does this cause frustration, but it also has a considerable cost in terms of lost productivity and wasted project time. How much time out of every hour do you spend context switching and looking for the right information? 10 minutes? 20 minutes? 40 minutes? That doesn’t leave much left for actual work.
- There’s got to be a better way. So, we asked ourselves: what might an ideal project collaboration solution look like? First of all, it needed to be able to be easily integrated into existing processes and individual behaviors. We really wanted to minimize change management. In order to stay on top of continuously evolving processes, configuring it and extending it needed to be as efficient as possible. It needed to help with project communication, so that we weren’t creating those hard-to-manage email threads and so that we could build a centralized store for project communications. We thought that it should be able to present applicable information to the right people at the right time. Our then-current systems tended to either show the same information to everyone (filtered for security, of course) or show completely different information to each user. We were looking for a collaboration system, so having some basic collaboration capabilities such as threaded discussions, a wiki, support for commenting on documents was a must. With respect to non-collaboration or CMS functionality, we were looking for a platform that could also loosely integrate to some external tools. We understood that certain functions just don’t belong in a content management or collaboration system. For example, it just doesn’t make sense to have your collaboration solution directly manage your build process, or track your bugs, or record your time sheets because there are dedicated tools that are so good at handling those specific tasks. However, we really wanted to minimize the amount of time project teams spent switching between those dedicated tools and searching for the appropriate information within those tools. To that end, we needed our collaboration solution to also act as a portal to these task-specific tools. And last—but definitely not least—we needed a solution based on an enterprise-class content management system. After all, at the end of the day, we’re talking about the information that runs our business, and we needed to have confidence that it is safe and secure. So, the obvious question that we asked ourselves was: How does Share stack up?
- And our answer was that it looked like a great match. Between the built-in collaboration functionality, the backing Alfresco repository, and the Surf platform—whose extension mechanisms we were optimistic about using to create our portal capabilities—it was almost a no-brainer to try Share for our project collaboration system. So now that you have an understanding of where we were coming from and what we were trying to accomplish, we’d like to show you what we’ve been doing with Share. Josh will now demonstrate a few of the ways we’ve been using Share.
- Thanks, Josh, for that great walkthrough of our project collaboration site. Before we turn over the bridge for some Q&A, I’d like to share a few final thoughts and sentiments we had about our experiences with Share. Share and Surf were pretty new to us when we set out to build this solution, and based on experiences with other collaboration systems and CMS’s, we were prepared for a bit of an uphill battle. We were pleasantly surprised that adapting Share to our specific business needs was actually a bit easier than we had expected. In retrospect, I think this is for a few reasons: First off, we found the webscript architecture to be really easy to use to quickly build new functionality. Compared to the world where server restarts are frequently needed to make any interesting changes, the simple “Refresh Web Scripts” paradigm was quite refreshing. Secondly, the community was a great help. There’s a ton of formation out there that helped us get rolling, and we see the community as a hugely important part of the whole Alfresco story. We really take this to heart, and we’ve decided to contribute back in a big way. We’ve got some plans in the works, and I encourage you to keep an eye out for upcoming articles and sample code we’ll soon be publishing. (As a side note, if you are interested in being notified when these articles come out, please just shoot me an email.) And finally, there’s no better tool when putting a complex solution together than to have access to the full source code. In those situations where we weren’t able to find answers in the community, all we had to do was walk through the source. I tell you—it’s much easier to learn how a system works when you can see “under the hood!” Another item we’d like to mention is that Share’s concept of “Sites” maps really well to projects. First of all, we have a single interface where project teams can and do access almost every piece of information they could possibly need. Also, being able to quickly and easily create sites pre-populated with every piece of project process collateral that’s needed is a real productivity booster for us. Along those lines, I’d like to call out that we’re really starting to see some great results from the Wiki, CMS, and Collaboration combination that share offers. Our project teams don’t need to context switch nearly as much as before, and this has really led to less wasted time and more satisfied team members. And as a final thought, I want to state again that you should really draw a line between what functionality you place in a collaboration solution and what belongs in dedicated, purpose built apps. I think Josh put it great before when he said: folks with Excel tend to see every problem a spreadsheet. Well, we’ve seen similar behaviors with collaboration, and I just want to recommend that when you decide to give Share a whirl around the block, to not look at every problem as a Collaboration problem.
- If you have any questions about Share, Alfresco, or ECM in general that you would like to ask offline, please don’t hesitate to reach out to us. Whether you have a pressing need and want to “sample the fish food” or are just looking to talk, we’re happy to help! And with that, let’s start the Q&A.