Project Management

Project Management 2.0

by
New technologies, concepts, and Web 2.0 tools are popping up everywhere. How can you use them to help your project team collaborate, communicate - or just give your project an extra boost? [Contact Dave]

About this Blog

RSS

Recent Posts

Are You Prepping For The PMP 24/7?

Are You Just Too Darn Busy?

Eliciting Requirements... Creatively!

What To Expect When Your Stakeholders Are Expecting

8 More Templates to Save You Time

Categories

Advice, Certification, Collaboration Tools, Decision Making, Estimating, Interviews, Learning, Management Approaches, New Templates, Personal Productivity, PM Software, PPM Software, Presentation Tools, Reporting Tools, Requirements Management, Research, Risk Management, Scheduling Software, Security, shameless self promotion, Techie Tools, Time Killers, Time Tracking Software, Training, Virtual Team Tools, Web-based Tools, workshops

Date

Large-Scale, Lightweight Reporting

linkedin twitter facebook Request to reuse this  
Situation: You need a robust reporting solution, but don't want a full-blown data warehouse.

The whole business intelligence thing can be fairly daunting.  Implementations can be costly and complicated when sometimes you just need "more reports, faster".  JReport is one of the software tools that can help get you there.  We recently spoke with Whit Mathis, VP of Sales at Jinfonet, who gave us some insight into when this sort of tool might be right for you.

Q. What are three things that people often forget when creating reports?

-The type of architecture required and flexibility of the reporting application.  It is very easy for reporting requirements to become complex and JReport reduces that complexity with simple, straight forward architecture (less hardware), yet is flexible enough to meet demanding reporting requirements.  Large BI vendors can require complex configurations for installation and on the other side Open Source vendors often do not have the flexibility to meet enterprise BI requirements.

- Considering future reporting needs and how they will change/adapt to those new requirements.  JReport is very extensible and can meet embedded BI requirements now and those to come.

- Some users will want to create their own reports easily or chose their own data to view.  JReport offers Adhoc capabilities which empowers the end-user to view the data they determine relevant.


Q.  What makes JReport different from its competition?

- Completely Java based with robust functionality.
    A major credit card processing company wanted to integrate their existing Java architecture that is used for their mission critical applications with a robust reporting platform.  JReport offered a fully compliant java solution along with all the features they needed to support 1000's of users.

   Our ISV customers, which represent many top tier technical companies, use JReport since they can have a very small resource footprint in their applications, yet offer value add features to their end users.  With the ability to white label our application, this creates a competitive advantage for the solutions which embed JReport.

 
Q.  What skills and knowledge enable a user to effectively use your report designer?

-JReport provides IDE that makes using the report designer very straightforward.   Customers that understand data relationships and how reports should look will easily be able to create highly usable business data.  JReport also provides professional services to those who need assistance with this or would like jump start.

 
Q.  Which types of reporting are perfect for your software? Which are not?

- We’re good for extremely lightweight, powerful reporting
- We’re good for departments who need a solution that can adapt to specific reporting need or an enterprise that does not need to be integrated with a Data warehouse.
- We’re good for challenging performance and scalability requirements.
- We’re good for business users that need real time access to data but do not want to learn complex reporting platforms
 
-We’re not perfect for big, overarching BI + data warehouse architectures or small, one-off reporting fixes
-We are not good for very simple reporting with small user base
- We are not good for anyone stuck on excel spreadsheets for reporting because they won’t utilize the capabilities that a robust reporting solution like JReport delivers.
Posted on: March 01, 2008 12:47 PM | Permalink | Comments (0)

Truth (or Clarity) in Scheduling

linkedin twitter facebook Request to reuse this  
Situation: You need a more accurate project schedule (and who doesnt?).

The inspiration for the whole Agile movement hinged on the fact that we all know that linear schedules are usually wrong.  The more complex the project, the more that is true.  Agile approaches are one way of dealing with that uncomfortable truth.  Another is to use a really interesting approach offered by the folks at Liquid Planner.  Recently,  we spoke with Charles Seybold, their CEO and founder who offered us some insight into how the tool works.

Q.  Liquid Planner uses date ranges and probabilities to deliver a more accurate view of project progress.  It’s pretty clear how that could be more accurate than any single date.  Could you talk a bit about how input from team members affects deadlines? 

First off, we don’t actually have an entity called a deadline in LiquidPlanner. Rather we have expected dates which we mark with a big [E] on the schedule (these are always flowing) and we have promise dates which are shown on the schedule with the traditional black diamond of a deadline.  The key is to manage to the [E] but set your promise dates at the end of the bars (which are drawn to the 98% confidence date). Setting the promise date “locks” your commitment and you will get an alert if any action puts those promise dates at risk. Any item can have a promise date, but they work best on projects and deliverables.

By asking team members to estimate in a range you are giving them a mechanism which allows them to be honest. Most things have intrinsic uncertainty so we just cannot be that precise. For instance, can we really say we will be done in with exactly 10 days of effort?  If the person says 9-11 days, that tells you they probably have it under pretty good control. If they say 5-15 days, that says something is not well known and that working to understand the requirements better might pay off. 

What really is a single point estimate?  It is the expected case? Best case? Worst case? A sandbag perhaps? 

It’s fun to note that estimating in ranges pretty much eliminates “sandbagging”.  This phenomenon happens when single point estimation meets experience. The experienced worker knows that they need to give estimates they feel 90% confident in so that they will not get dinged for a miss, but when you estimate at that level, 9 times out of 10 you’ll be early.  When that happens the worker can sometimes fill that time with things that maybe were not part of the plan and… well you know the rest. Single point estimates are just bad for relationships.

The other great thing about a team member capturing uncertainty is that it inherits through their chain of prioritized work so that the exit dates on later work get a correspondingly higher about of uncertainty even if they are small tasks. This makes sense because if the exit date of your first task is uncertain, the start date of your next task is uncertain.


Q.  I personally like the Liquid Planner interface from a usability perspective.  What unique steps did you take to test Liquid Planner before its release? From a usability perspective, how do you think it compares to other Ruby on Rails PM apps like Basecamp? (using specific examples)

I’ll interpret your question broadly. In my previous corporate gig like I spent a great deal of time working on planning tools (mostly Excel based) where we were modeling concepts like ranged estimation and flowing work. From basically the first week of LiquidPlanner’s existence, we started prototyping. I maintained a prototype in PowerPoint that we used to mock up every feature we added and I kept that prototype up to date with the work the dev team was doing. This allowed us to test designs very early and make very rapid decisions and modifications for the UI. In short, it was try-fail-learn at a very fast, ridiculously lost cost rate. Looking back at my archive, I see over 200 versions of prototype. This allowed us to narrow in on a design that felt right to us and our friends many months before we put it in the hands of Alpha customers.  Even with that, we’re not perfect; we found some things that needed rework in our private alpha and I expect we’ll find and fix some things in the beta.

We are built on Ruby on Rails and drew inspiration from what the 37 Signals crew accomplished. We like Basecamp and think they did a great job showing the world that web software could be easy. There are many applications out there that are basically Basecamp clones and we think there is no point in repeating that again.  Our goal with LiquidPlanner was to take on a much broader set of objectives for a higher level of professional planning. We wanted to build for a greater scale with hundreds of projects and thousands of tasks. We wanted to be more like a desktop application.  LiquidPlanner is designed to be a platform for project management which, over time, will grow to serve large enterprises while staying true to our belief that the most important feature is usability.  Since you asked for an example, I’ll point out that many of the lightweight online task management tools are not built to put a ton of data in them. LiquidPlanner is build like a data warehouse and uses rich work breakdown structure as the backbone of your collaboration data so that your discussions, documents, and reports will stay organized as you reorganize your plan.


Q.  I really like the idea of everyone owning the schedule, based on their direct input.  Are there typical ways outside of the tool that PMs motivate team members to give honest input (versus padding their tasks) so that you can maximize accuracy?

None that we know of that work with other tools on the market.

Fundamentally a single point estimate is interpreted as a promise and this means that people will negotiate or obfuscate through them. A pattern we see is that the estimate giver and the estimate taker often do not have the same skill level in negotiation and the estimate giver gets backed into what we call “the least defensible estimate” which lies very close to the optimistic estimate.

Some techniques for getting better estimates from your team are tee-shirt sizing, wide band Delphi, and estimating by analogy but they all embrace notions of uncertainty and calibration.  Group estimating is quite effective even informally.


Q.  You talk a lot about “one source of truth”.  How do you see requirements playing into that “single big picture” view of the project, when using Liquid Planner?

Another word for truth is clarity, and any process that you can bring more clarity to is what we are talking about.  For example, in my last company we had a full SDLC and wrote specifications full of requirements for development work. We had a system of rating the specs 1 through 4 based on their “readiness” for Dev; level 4 meant it was done. In practice this was a binary state – not ready vs. ready.  I submit their would be real value in a ranged estimate at these stages to capture a meaningful metric regarding how much uncertainty exists. I think the feedback would be super useful to the person responsible for the requirements as well as a manager who wants to be able to direct her efforts to the projects with the most uncertainty.  If you want to take it a step further, you can do what we do, which is spec requirements in LiquidPlanner and let the projects, categories, and work items carried those requirements with them. That way each item can be assigned and estimated as you go and you can use uncertainty to guide your management actions. It’s the best way to facilitate one of my favorite practices: cut early and cut often.
Posted on: February 25, 2008 04:57 AM | Permalink | Comments (9)

A New Way to Look at Search

linkedin twitter facebook Request to reuse this  
Situation: You need a to increase your search speed.

ManagedQ isn't another search engine.  It offers an interesting new - visually logical - way to look at search results.  This is the sort of thing you have to try to really understand, but I think it has a lot of potential.  On the left-hand tool bar, it breaks down the search results into  People, Places, and Things.  In the main body of the screen, you get screen snaps of the results under each category.  So you immediately see where you are going.  It's like the difference between having your headlights on or off as you drive down the road at dusk.  You react a little more quickly and perhaps get where you are going faster.  -- kind of  like a more advanced version of Ask.com's pop-up previews.

Again, a picture speaks a thousand words - so go ahead and give it a try...
Posted on: February 23, 2008 09:48 AM | Permalink | Comments (2)

Did You Know You Have 5GB of Free MS Storage on the Web?

linkedin twitter facebook Request to reuse this  
Situation: You Need a Little More (Hard Drive) Space.

As part of its LIVE program, Microsoft offers SkyDrive, FREE storage on the web that you can use as back up space, a place to share large files - or anything that the pack rat in you demands you keep.  Obviously lots of vendors do this, but 5GB is lots of space for free and MS will likely be around for quite some time.

The SkyDrive is linked to (really sort of the back-end for) Spaces, which is Microsofts answer to Facebook.  If you are an MS Messenger user, this might interest you as well.


The whole LIVE scene is completed by OfficeLive, the SaaS (really lite online) version of MS Office which I've reviewed in past postings.
Posted on: February 22, 2008 02:08 PM | Permalink | Comments (0)

Mash-ups and PM, What's the Deal?

linkedin twitter facebook Request to reuse this  
Situation: You Could Use a Little Mash-up Primer.

PMs deal with reporting a LOT.  Whether you are dealing with reporting on projects within the enterprise, or building an enterprise app that has a strong reporting component, its good to know a bit about how mash-ups might play a role in your overall approach.  Recently, we spoke with Chris Warner at JackBe - who gave us some quick answers to questions I think many of us share.



Q.  What’s a good example of a Project Manager using an enterprise mashup?  Do you see them being used to actually manage projects or are they more a class of applications that many PMs will be involved in implementing?

Everyone seems to have a gut ‘feeling’ for mashups.  And many of us have played with the proverbial ‘Chicago apartment locator’.  But defining a mashup in the context of the enterprise is another story.  So let’s start with an example of a sophisticated enterprise mashup: connecting your SAP ERP data with your Oracle/Siebel CRM data and two sets of online third-party demographic information while maintaining single sign-on through your global LDAP server, then sharing the mashup with your management.  And doing it without IT’s involvement.

A good definition of an enterprise mashup would be ‘a user-centric micro-integration of Web-accessible data’.  While short, this definition contains a number of important points worth considering:

•    “User-centric” – Mashups are always intended user consumption and are often created by the users themselves, not the by black-box back-end integration systems such as ESB, BPM, BPEL, etc.  Without this guiding principle, we are merely sending the users back to IT for more development.
•    “Micro-integration” – Think of a user taking data from multiple sources and copying it into Excel.  As these users typically deal with small amounts of knowledge-oriented information (as opposed to IT-managed applications that typically deal with large amounts of transactional information), these are called “micro-integrations”.   
•    “Web-accessible” –Mashups are best created from standardized data formats such as WSDL, REST and RSS, which we summarize here as ‘web-accessible’.  In other words, our data sources shouldn’t require too much manipulation for the user to make sense of it.

It is important to note that this describes what an enterprise mashup is but not its usage.  That is left to the user, whether that user is an intelligence analyst performing an evaluation of a terrorist hotspot or a securities trader completing an analysis of an interesting investment opportunity.  More importantly, the way a user interacts with a mashup makes it distinct from IT-centric integrations.  Users dynamically create and interact with mashups.  The net effect is that IT doesn’t prescribe the integration, they only need to provide a framework to govern their creation.

With all this as background, it is reasonable to expect that enterprise mashups will be both a tool for Project Managers and a part of the new class of ‘Web 2.0’ applications PMs will be involved in implementing.  As a tool, enterprise mashups can greatly improve the real-time decision-making capabilities of a PM.  And JackBe can attest that mashup adoption in industries like financial services and government has already begun; some PMs are already learning what it means to deal with this new style of ‘Web 2.0 mashup application’ with requirements like ‘loosely-coupled’, ‘user-driven’, and ‘browser-based’.


Q. At a portfolio level, executives often use Enterprise Project Portfolio Management Tools to organize and prioritize projects.  For example, the Daptiv Product Suite has a Cognos back-end that allows access to project data via a data warehouse.  If I’m trying to manage a portfolio of projects, do enterprise mashups replace some of this functionality or is it complementary?


Mashups are very complimentary to today’s popular reporting/analysis tools.  Enterprise mashup solutions provide users with the ability to mash data from a data warehouse/mart as easily as any other data source.  A good example would be mashing your warehoused project data with third-party resource availability/cost data in real-time.    

But it’s also worth noting that mashups don’t require a warehouse/mart.  Mashups can easily be constructed from transactional ERP/CRM/SFA systems and newer interface technologies like SOA and RSS services.  Mashups can make these disparate technologies easy to dynamically combine for real-time information solutions.


Q.  What is the most common executive dashboard application created via a mashup?  What is the most unique one you’ve seen (something that would not have been possible with older technology)?


Common dashboards constructed from enterprise mashups have been in executive hot-spots like real-time financial benchmarking and regulatory compliance.  The most unique enterprise mashup application is certainly Project ‘Overwatch’, the real-time intelligence briefing interface JackBe helped build at the Defense Intelligence Agency (there’s a short case study online).  They’ve replaced the low-tech cut-and-paste into Powerpoint approach with a rich browser-based interface that connects live to data sources.  Every briefing can be given based upon real-time, live information and that information can also be shared collaboratively among analysts.  This is what Web 2.0 is all about.  PMs and their clients will all come to expect this kind of dynamic information in the near future.


Q.  Mashups seem to make data and reports more directly accessible to executives, allowing them to dream up reports and easily pull them together on the fly.  How do you think that will change the nature of future large scale application development projects?  


In general, mashup applications are the antithesis of the ‘big bang’ software projects of the past.  These are constructed from data sources that have standardized interfaces (making them easy to assemble) and are deployed as ‘containerized’ micro-applications that are built from browser-based ‘rich internet’ technologies like Ajax, Flex and Silverlight (making them easy to embed in websites/blogs and making them easy to share with others), and they are often created by the users themselves.  As we often say at JackBe, enterprise mashups can be constructed in minutes, not months!


Posted on: February 22, 2008 11:44 AM | Permalink | Comments (0)
ADVERTISEMENTS

"If opportunity doesn't knock, build a door."

- Milton Berle

ADVERTISEMENT

Sponsors