Dave McNamee: Web Stuff

New Portal Efforts

Fri, 15 Aug 2003 15:19:01 GMT

I am assisting key stakeholders from different State agencies in building a new State Enterprise Employee Portal project. The project team has not yet been formed, but we have a pretty good idea of who needs to be involved. Obviously DHRM and Finance have a major stake in this project, so their involvement will be extensive. No employee portal would be complete without the services that those organizations provide. I am very excited about this new effort, because, unlike previous efforts, it is being driven by business owners rather than by technologists. Also, it has the support of the CIO and will become a fully sanctioned enterprise project if we do things right.

Meantime, other "portal" projects are in search of direction. Public Safety has a couple of efforts that could benefit greatly from solid enterprise strategy for portals. This strategy does not exist yet. I hope to help pull people to solve this portal meta issue. It is possible that we could create economies of scale with portal efforts, and at the same time work towards integrated presentation of services provided by State government.

Commonly Held Assets

Wed, 13 Aug 2003 14:31:14 GMT

ITS is the custodian of the State's largest and best equipped data center. Notice I wrote ITS is the custodian of this data center. We have not always acted that way. In fact, we still use terms like "our data center" or "come host at ITS' data center." Wrong. This is a facilty that is available to all State agencies. It is the State's data center.

Now, you may say, "well, how can it be the State's data center if ITS is responsible for recovering the cost of it?" That is a good question, but I don't think that having one agency have custodial and operational responsibility for the facility is mutually exclusive with it being viewed as a commonly held asset. ITS should only be the managing partner.

To further explain what I mean, consider this example: 3 guys go in together and buy an airplane. They discuss how to manage the finances of the airplane, and decide on an hourly rate for operations which will cover all of their costs. They ask the pilot with the most experience out of the three of them to collect the money from each of the other partners and arrange for maintenance, a hangar, insurance, etc. Now, I am not familiar with the financing arrangement that built the Salt Lake data center, but it belongs to everybody, and ITS is simply the senior pilot who manages things.

Certainly, there are adjustments that ITS should make. We need to stop calling it "our" data center, unless by "our" we mean all State agencies. I also believe that there are changes that we could make that would make it a more attractive place for agencies to bring their stuff. I will be working on this.

AOL and Google to offer Blogs

Mon, 28 Jul 2003 16:26:39 GMT

RSS and weblogging are getting some serious attention these days. See this InfoWorld article for an example. AOL and Google are investing time and resources to get into the blogging market space, and reputable news organizations everywhere are supporting RSS. It looks like people are recognizing the value of this open medium.

Also in the article from InfoWorld is a discussion on Echo (aka Atom), a new standard that is supposed to overcome some of the limitations of RSS.

Organized RSS

Thu, 17 Jul 2003 13:04:59 GMT

RSS is a powerful content aggregation tool. It is useful in more applications than just blogging. At ITS, we have developed an RSS tool that will make it available to state agencies for creating things like press releases, articles on www.utah.gov and on business.utah.gov, the new doing business in Utah portal and soon to be the home of One-Stop Business Registration. This RSS tool is called news.utah.gov.

News.utah.gov is not intended to be a blogging tool for personal weblogs, however it works in much the same way as a personal weblog. It is based on the Movable Type blogging platform, but again, it is not intended to be a blogging tool. The types of news feeds that are out there now are things like "Utah Business News," which is being consumed right now on busines.utah.gov. Control over the feeds that are created will be very strict.

News.utah.gov is also an example of a project that used existing code bases to develop an effective application that can run in an inexpensive environment. The environment this is running in is a LAMP (Linux Apache MySQL PHP) environment. ITS should be adding LAMP to its hosting product portfolio this year. I am the hosting product manager, so I will be working towards that end.

Websphere Portal

Mon, 16 Jun 2003 20:27:37 GMT

Well, I worked on a long blog entry to describe the Websphere portal server demo, and clicked the wrong button and lost it all. Sorry. If you want details on it, please let me know.

Suffice it to say that it looks pretty good. I didn't notice any features that were obviously missing. It seems to have everything that Novell's exteNd product has, with the addition of a powerful development tool, WS studio. It also integrates with existing systems. Again, email me if you want more info.

IBM Web Services Demo

Mon, 16 Jun 2003 16:40:41 GMT

I am attending an IBM "e-business on demand" pitch right now. I have to admit, so far, the presentation has been interesting. They have an impressive array of platforms running on multiple laptops, including a Linux laptop.

This is basically a websphere app server/websphere developer studio/rational rose demo. Of course, they are starting the day with a demo of web services. I am sad to admit, this is the first real demo of a running web service, a real web service, that I have seen. They just showed us a web services demo where a .Net app called a websphere-based web service. They have two projectors up, one showing the client app and the other showing the server console so we can see the actual calls. Cool.

Being a Java vendor, they are taking a lot of time to demonstrate the differences between .Net and Java. They are preaching to the choir. I used to develop Java apps before making the fabled switch off the "technical" track and onto the "management" track. As far as I know, no state agency is using .Net.

These demos bring several questions to my mind:

How soon will agencies want to create web services?
What should our enterprise strategy for Websphere be?
What about Linux on the mainframe?
How can ITS get ahead of the agencies and lead in the development of web services?
What infrastructure should we build to handle future demand?
How can we do all of this and provide the best value for taxpayers?

I'm goning to have to chew on this quickly. Customers are waiting.

Shrinking Community

Tue, 06 May 2003 17:32:42 GMT

I have a few spare minutes, and Dave Fletcher has shamed me into updating my blog. A lot of folks have pretty much abadoned blogging, but I am not one of them. It's not that I don't want to update my blog, it's just that I really haven't had much that I thought you, my loyal readership, would be interested in. Until now.

One of my products is portal services. What is it, you ask? Well, that's a complicated question, and one that I wrote about previously. I have seen several demos of potential portal solutions, including MySAP, Sieblel, NPS, and we will probably be seeing more. There's a lot of movement, but not much strategy. I am working to change that.

My nirvana would be an integrated portal strategy, at least for employee-facing services. I am pushing for that. There really is a lot of potential for integrating systems and making the lives of state employees easier. The issue, as usual is not technology. It's figuring out how to bring all of these disparate efforts together under some semblance of a strategy. If we succeed at that, I will let you know. You will probably hear if we fail, too.

Portal Product

Mon, 14 Apr 2003 13:40:54 GMT

People use the word "portal" to describe a very wide variety of things. In State government, we have a lot of different initiatives that use the word indiscriminately: Utah.gov portal, Payment Portal, Homeland Security Portal, Utah Enterprise State Employee Portal, etc. So, what is a portal? And what does ITS, the agency I work for, have to do with any of them?

Those are fine questions. As the product manager for ITS portal services, they are mine to answer, at least for ITS. First of all, let me tell you what I think a portal is. A portal is a web site that:

Aggregates conent from different content providers
Provides customization and personalization options to users
Is dynamic in content, and connects users to related services available through the web

A site with a collection of links is not, in my opinion, a portal. Niether is an online payment collection service. The fact that the word portal is used in conjunction with both link collection sites and payment services obscures what I think a portal really is.

ITS is faced with several questions regarding portals. The following paragraphs describe those issues.

A couple of years ago, ITS built the "Innerweb" which is the current employee portal. In my opinion, it meets the definition of a portal. It is not widely used and is somewhat of an orphan, but it is a portal. It was built on an application server platform that we would like to stop supporting in the next year or so, which gives ITS an incentive to figure out what will replace it. Last year we headed an effort to create an enterprise employee portal. This was done in conjunction with the Teamsite projcet. The problem was that we were building it the same way we built Innerweb, without any clear business ownership. The project was stopped without completely resolving the issue of ownership. In my opinion, ITS should not be the driving force behind the next employee portal.

Another question facing ITS regarding portals is what is our role in creating them for agency business owners? Should we provide a portal development product? I would say a tentative yes, but it remains to be proven out. If we develop a portal development product, then we can offer packages that connect the portals we develop with other State IT infrastructure, such as authentication and UMD. I am working through a plan to figure out exactly what ITS should do about this opportunity.

Finally, let me say that I don't think that every site has to meet the definition of a portal described above. In a lot of instances, it is perfectly appropriate for a site to simply be a collection of links. In other cases, increased value to the user could be possible if sites moved towards my definition of a portal.

RSS for State Government Sites

Wed, 26 Mar 2003 16:43:57 GMT

RSS is a very powerful tool. It makes it possible for site owners to syndicate their content, as well as consume the syndicated content from other sources. If agencies created RSS feeds and consumed each other's feeds, information would be more readily available and it would be a good thing.

Intrepid managers of State IT efforts recognize the value of RSS. Dave Fletcher is working to make the creation of RSS simple for agencies. Also, Utah Interactive is in the process of developing a new State business portal, which will feature RSS feeds from various agencies.

RSS is powerful because it makes content available while still allowing site administrators the freedom to decide how the content will be presented. It makes the process of sharing content free from human interaction. Anyone could take the URL http://radio.weblogs.com/0110870/rss.xml and subscribe to the RSS feed for this weblog. The content is there, available for any parser that speaks RSS 1.0 to consume, process, and post on any other site. This is done without actually having to download the content onto the consuming server.

I have an opinion on how the State should approach RSS, which I will share with you here.

I believe that RSS will not achieve its full potential on State websites unless agencies catch the vision and actually create and host the feeds themselves on their web servers. We should sell agencies on the virtures of RSS, and help them create the feeds and post them on their servers. We should also help agencies determine how they would like to consume RSS on their own sites. If we simply create a centralized RSS server and ask agencies to put their press releases there, they will never go beyond that. It will simply be a content contribution system. If that is what we want, then we may as well just have the agencies email the content to a site administrator, because even with RSS, someone ought to look at the content before it is posted.

If they catch the vision of RSS and create and manage their own feeds, then the value of RSS is preserved. No middle piece would be needed to create the feeds for them or manage where they went. It would be pure, powerful RSS. I think using the business portal project as a test case for this would be a good thing.

Anyway, that's my $0.02.

Teamsite Consultant

Mon, 17 Mar 2003 16:35:49 GMT

Tom Brown, a consultant for Interwoven, is here to look at our Teamsite installation and see if he can demo some things successfully for us. After he gets things set up, we will show the product to agencies and get their input, if they wish to give any.

At any rate, a final recommendation regarding Teamsite will be produced shortly, with a final decision from management coming shortly thereafter.

UII and Co-Loc

Tue, 11 Mar 2003 14:16:02 GMT

Yesterday I attended a joint ACIO/Product Management Council meeting. The topic was the renewal of the Utah Interactive contract and web hosting in general. For those unfamiliar with the history of web development in the State of Utah over the past 4 years, Utah Interactive, Inc (called UII by most state folks, UI by those who work there) has been responsible for a large amount of progress towards getting services online. They basically own and run the Utah.gov portal, and they have successfully created 70+ web applications for a multitude of state agencies. They have done a lot of great work in a time where there really wasn't anyone else to fill that void.

Well, their 4 year contract expires sometime in May, and the discussion at the meeting yesterday centered around renewing the contract, and on where their applications will live. Today, all UII apps live in their own facility. ITS attempted unsuccessfully last year to migrate their apps to our iPlanet environment. UII uses Linux. In order to bring those apps into a more controlled environment, it has been decided that colocation is the best option. UII will bring their servers to ITS' data center where they will enjoy world-class environmental, network, and power facilities, not to mention physical security. I think this is the right thing to do. I also believe that renewing the UII contract is a wise decision, however, in order for eGovernment to mature, changes need to be made to our relationship with UII. I believe that the relationship should be more customer (the state)/contractor (UII) rather than partner/partner. I'm not discounting the value of what they have done, nor do I think our relationship should end, I'd just like to see the state take charge of its eGovernment destiny instead of outsourcing it.

Customer Connections

Wed, 26 Feb 2003 21:35:14 GMT

Several of us from ITS met with a slew of eREP folks down in American Fork to discuss UMD and authentication. We have had a lot of contact with them about UMD in the past, but we haven't really made a solid connection until this meeting. I basically described the whole shooting match on the whiteboard and we answered questions. I find that if our customers understand our products, they see how they can use them to accomplish their business objectives. Now, we have been talking to eREP and collaborating with them in the past, but I feel like we are moving into a new phase where they know and understand what we are doing and we know and understand what they are doing, and we work together to meet business objectives.

This is the kind of relationship that I want to build with more of our customers. I put out an email to some IT directors offering to come and describe UMD and authentication to them as well. It's extremely important that we get the word out. In the next little while I will post more information about UMD here on my blog, and elsewhere.

Directory Services and Web Authentication PRD

Tue, 25 Feb 2003 22:08:42 GMT

I finished an initial draft of the PRD for UMD/Auth/Auth/App Profile/Identity Management today. It has been distributed to our engineering folks for review. Tomorrow I will share it with the eREP team.

More on InfoPath and Archiving

Mon, 24 Feb 2003 20:18:12 GMT

I had an interesting conversation with some pretty smart guys over lunch today. Aside from laughing really hard and talking about aviation, we spoke about the methods of archival that we use today, and their short lifespans. File formats and storage media seem to obsolesce faster than you can say VHS. There is no standard persistent storage format that we can be confident about its longevity. For example, how long will PDFs last? It's really only a matter of time before some newer and cheaper format comes out that makes PDFs obsolete. As for media, who has an 8 inch drive anymore? Actually, one of our lunch companions claims to have one, but I am skeptical. As we develop new file formats, we misplace the old programs and devices that can read the old file formats. It's doubtful that any file format in use today will be commonly used 20 years from now, so what do we do with all of the data that we have archived? Do we spend the money every 20 years to adopt a new storage format?

Lest you panic and replay scenes in your mind from planet of the apes (the old one with Chuck Heston, not the new Mark Wallberg one. I haven't seen that one) where chuck goes in the ancient library and all the books have disintigrated, I believe solutions will be created that will release us from dependence on proprietary file formats, if not from perishable storage media. Now, I am not a professional archivist, so I don't know what is being developed, but it seems to me that we can make files with XML and create a XSD (XML Schema Document) that will tell new programs how to access the data. XML seems to abstract things out into a lowest common denominator, making the processing of the data accessible to any program that can read the XSD. Office 11 will have the capability of creating both types of documents (XML and XSD) using word, excel, or infopath. I have a lot to learn about this new technology, but it seems like we can figure this stuff out.

The application of this new XML technology will provide the State and organizations everywhere with new ways for managing documents and workflows. It's a convergence of sorts towards XML. One of my favorite movies is Contact, based on the Carl Sagan book of the same title (in my opinion this movie is an exception to the rule that the book is better than the movie. Not the movie is fantastic, it's just that the book wasn't all that great). In the movie, a message is received from the vicinity of the star Vega, and large amounts of information are contained in the message. It looks like a garbled mess until they figure out how to parse the data, and how to translate it into meaningful data using mathematics. I see archiving data working the same way in the future. We have to store a primer, a DTD, an XSD, a dictionary, whatever you want to call it, and that primer will tell those that access the data in the future how to read it. It's that or we go back to parchment scrolls.

Busride

Mon, 24 Feb 2003 13:37:31 GMT

Radio Userland software is pretty cool. I am sitting on the bus right now, on my way to work. Once I submit this post, it will go to my localhost and then as soon as I connect to the network in the state office building the article will be automatically uploaded the radio userland community server. Now if I only had Sprint WiFi service...

This is going to be a very busy week. I will be finishing my first rough draft of a PRD for UMD/auth/auth/ID management. I will be sharing this document with key stakeholders including eREP, DHRM, DPS, DWS, DOT, DHS, and DAS. This thing is so huge that the PRD will evolve over the next month, but our experience with DPS last week has proven the value of talking early and often with customers about the product. In the meantime, because there is so much work to be done to get the whole thing put together, development will continue. One major difference, tho, between now and previous development is that now we are working as a team, and everything will go thru a peer review process.

Wednesday we are meeting with the eREP team in American Fork. I have only been in contact with the eREP team for a couple of weeks, and already my understanding of their requirements and timeframes has improved significantly. Their needs are many and complex. Dan Cook at ITS and Dan Rossean (spelling?) at eREP are trying to keep everything straight, getting the right people to talk at the right time. That's a big job.

Also on my plate for this week will be activity on the "web services" strategic plan. This plan will address all of the web-related technologies and products that ITS offers. In the past we have not done a good job at packaging all of these services and combining strategy. Because of this we have not been as competitive as we should have been in the businesses of web hosting and web-related services. We have to improve to survive.

Workflow and XML

Fri, 21 Feb 2003 22:52:12 GMT

ITS has tried to create a workflow product in the past. Our efforts failed completely, but it is still in the back of my mind. And with the mid-year (according to microsoft.com) release of Office 11, I think InfoPath may turn out to be a tool that we could use to create a workflow/BPM product. I would sure like to try it.

You know, there are times when I wish I had time to dig down into the depths of technology and just learn it all. Alas, I have departed from the techie path (I did some Java and other web development during a previous assignment) and I am now firmly rooted on the management path. There's some cool stuff out there.

Weekly Wrapup

Fri, 21 Feb 2003 19:01:46 GMT

It's tough to sum up my work activities in a few paragraphs. But I will try. Some information is better than no information (unless it is taken out of context or misinterpreted. I guess my statement has a lot of exceptions. Oh, well, it's Friday, what do you want from me?).

I must say first of all that I am encouraged by the events of this week. I have been able to accomplish a significant amount of work. Most of my focus has been on Authentication/Authorization/UMD/Identity Management, which is where it belongs. I received a significant amount of information from the engineering team about the requirements for the whole system, and I am in the middle of combining their comments into the PRD that will be released on Wednesday.

Also, I went with Curtis Parker and Doug Law, two of our top experts on UMD and authentication, to DPS to talk to them about how they may want to use the system. It was a very productive and enlightening meeting. We discussed issues that we have not yet addressed, and helped them understand our intentions for the system. At the end of our meeting our new CIO, Val Oveson, stopped in to chat with the group about his ideas. I think Val is the right man for the job right now. He and Windley are both extremely talented guys, but Val is a natural fit into this environment. Anyway, we will be doing more of these "roadshow" things in the near future.

My content management product is languishing somewhat. We have to prove that Teamsite 5.5.2 will work, and that TCO isn't too high for it to be successful. This can only done with and upgrade and a proof-of-concept, which I am depending on Engineering to do for me. In the meantime, my boss has purchased copies of Macromedia Contribute for us to begin creating more product-related content for the ITS sites. No formal workflow or staging, but those are problems that are easy to overcome. Plus, the state gets a break on the already-cheap licensing fee. I'm not saying there isn't a potential for products like Teamsite to be successful, but I am saying that it is silly to limit choices to the agencies.

UMD, Authentication, Authorization, App Profile, and Identity Management

Thu, 13 Feb 2003 22:12:56 GMT

I think you can tell by the title to this post that this is no small thing. We're really talking about a major piece of enterprise infrastructure. If we do it right, this will be a huge part of almost every web application offered by the State. It is a huge part of the Governor's initiative to bring government services online.

With that said, we have languished for too long without a proper product requirements document (aka a PRD. Get used to that term because I will be using it extensively) that ties all of these interdependent systems together and describes what they will be and what they do. It's a big task, but there really is no way to separate the requirements for UMD, authentication, authorization, app profile and identity management. I will be releasing the first version of the PRD on the 26th of this month.

What follows is a brief update on each of the components of this system to tide folks over until the PRD is done.

Here is the deal with UMD: the State employee side is working with synchronization between HRE, UMD, and individual resource trees. On the public side, we pretty much have the schema determined. In other words, we know for the most part what data elements we will store for each user. However, we do not have the mechanism built yet that will migrate customer data and create new users (see identity management).

Authentication. SiteMinder 5.5 developement is moving forward. Our engineers are working through some unresolved technical issues and building the login screens.

Authorization. This is probably where most people are confused. Authorization, unlike authentication, can be implemented multiple ways. The thing to remember is that SiteMinder performs authentication and authorization every time a browser requests a protected resource. Period. That's how siteminder works. Now, you can tell siteminder to just check username and password and then do all the rest of your authorization with your application, but siteminder is still doing authorization in this case. Basically, the authorization step that it takes is to check if you are in the directory, and any member of the directory is granted access to the resource. Siteminder can do a lot more than that, and we will be articulating this fact in our PRD, so app developers know what is available and how things work. I believe we will be discovering a "most efficient" way to do authentication and authorization.

App Profile. This is the thing that allows applications to store information in the directory. It also deals with granting access to resources, and controlling the scope of administrators. App profile is where authorization information is stored. We have a very talented engineer working through the challenges associated with this problem. I would guestimate that he has about 90% of it figured out, and I gotta say I am impressed.

Identity management. Our engineers have an idea how this is going to work, but I think this one is the farthest from being figured out. More info to follow.

Actuate

Thu, 13 Feb 2003 20:52:17 GMT

ITS is 100% committed to Actuate. We are aware of the fact that several of our customers (I can think of 4 at least) that depend on Actuate to provide mission-critical reports. We have been working on making our Actuate environement for several months now, with the ultimate objective to provide a world-class Actuate 6 environment with failover, page level security, and development, test, and production environments.

There were three major steps to upgrade to 6. First, we have to lock down our current environment. By lock down I mean restrict access to those tasked with maintaining the environment, and send all reports through acceptance testing procedures to ensure that production is not adversely affected. We have had meetings where we invited all of our customers and explained this process to them. The second step is to finalize the implementation of 6 and provide a migration path from 5 to 6. The third and final step is to move everyone off of 6 and phase out 5. Once all of these steps are completed, we will have a world-class Actuate hosting environment that will meet our customers' reliability, availability, and serviceability requirements.

Currently, we are on the first step. In order to lock down test and production, we needed to provide a development server. We have had some difficulties getting our development server to run properly, so in the meantime, developers are continuing using our test server. Project management is helping engineering and others work through the issues, and I have been in contact with customers to guarentee to them that they will always have a server to use for development. Customers with specific and unusual requirements are getting extra attention. Once we have things resolved with our development server, we will make it available to developers and let them know when the other servers will no longer be available. We will work with them to ensure they have what they need on the new development server. I don't see the process of completing step 1 lasting more than a couple of weeks. After that we move on to step 2. Also involved in step 2 is providing an Actuate 6 development environment so agencies can prepare reports for the new environment.

Teamsite Content Management

Thu, 13 Feb 2003 20:25:03 GMT

Before reading further, please go back and review my posts from 21 and 22 January on the subject of Teamsite. They will provide you some context.

Here's the deal now:

We have been in daily contact with the vendor to gather resources and information for upgrading to version 5.5.2. I hope to have a project plan next week for installing 5.5.2. After we install 5.5.2 we have to prove that it delivers the promised features, and we have to ascertain the costs for customer provisioning, training, support, etc. I believe there could be a place for Teamsite if we can provide the environment for a reasonable price. If it is too expensive to implement for agencies, they won't use it even if we subsidize the environment. We just have to prove it out. I will have more info for you next week.

UMD/auth

Mon, 10 Feb 2003 22:47:41 GMT

Sorry my blogging has been so sporatic and substance-less lately. I've had my head down, banging out product requirements documents.

We have combined the web authentication and UMD projects into one. I am currently working on a draft of the PRD for them. A lot of people have submitted information to me for inclusion in the document. Combining them eliminates some redundancy in meetings, so it is a good idea. As I get deeper into the details of UMD and web authentication, my confidence increases in the possibility that we will be successful. UMD is really closer to being what we need than was my impression, and a lot of thought has gone into solving problems that have challenged us in the past. I believe that the requirements that I am capturing right now will get us 95% of the way there. I will also be checking with customers to ensure we are creating something they can use.

This is an interesting project due to the fact that niether UMD nor web authentication are really stand-alone products. We won't package them up and sell them by themselves. Instead, other products like web hosting and external applications will consume them. How do I do P&L for it then? I don't know yet.

Refining My Activities

Wed, 05 Feb 2003 14:20:09 GMT

I thought I would give you another update on my products/projects. I am having some success at refining my activities to those that more directly apply to product management rather than project management. I have received a set of objectives from my management, and they specify the activities that I am to be engaged in. A more focused approach to specific product management work is needed in order for me to accomplish my objectives.

We are in the process of capturing requirements for directory services, or UMD, for authentication, and for authorization. A lot of development on UMD has taken place, and DirXML connections to HRE and other resource trees have been created. However, we need to take a step back and capture requirements. Authentication, authorization, and directory services (identity management) have been combined into one project. They are inextricably tied together anyway, so combining the projects just acknowledges that fact. We are moving with a sense of urgency. A lot of products/projects depend on this.

We have also made significant progress in determining what it would take to offer content management services through Teamsite. We are in contact with the vendor discussing an upgrade to version 5.52, which apparently will "solve all of our problems." It is supposed to run swimmingly on Solaris, Front Office should work, and it should eliminate the need for Samba shares by making calls through SOAP. In addition to the vendor, I am also in touch with local content management firms that have implemented Teamsite and can help me with a business case.

From 5th to 3rd

Wed, 29 Jan 2003 19:54:09 GMT

In my previous post I wrote about the need for PRDs and strategy. The time has come for me to focus more heavily on producing those documents that are needed for my product. Until now, I have been heavily involved in project management, and in operational affairs. I am going to have to back away from those activities and focus more heavily on writing.

This transition from heavy involvement to necessary involvement can only occur under the following circumstances:

There are sufficient project plans and project management resources in place to cover project management needs. This is difficult because we have even fewer project managers than we have product managers. Project management is an intense responsibility that requires focus and dogged-ness.
Operations and CRMs need to take the lead in customer communications. I shouldn't be worrying about operational communications. Of course, the job of the product manager is to be a customer advocate, but I should not be coordinating testing schedules.
Any project that is not UMD, Content Management, or Authentication is going to have to go on the back burner.

It is dificult to pull away from activities that accomplished something, like the AT environment project, but I gotta do it. It's like travelling up a hill at 65 MPH and shifting from 5th down to 3rd. The thing is going to make some noise, and it may slow down some, but it has to be done.

More on Teamsite

Wed, 22 Jan 2003 19:21:53 GMT

Yesterday I wrote about the issues that would need to be resolved before we could offer Teamsite as a product. Today I want to write about the first step: Front Office.

We have learned from extensive and expensive experience that using Teamsite templates for content contribution will probably not work for most agency implementations. It is expensive to set up and requires a fair amount of training. Teamsite was sold to the state on the basis that you could use a feature called "Front Office" to make content contributions from regular office suite tools. Front Office is really the only path to a positive cost-benefit ratio for our customers.

With that said, I must now report to you that Front Office has not yet been successfully deployed. The consultants were released just as they were in the middle of tackling that problem. They had Front Office installed on a customer machine, but they were not able to make it work. If we can't get Front Office to work, it will be extremely difficult for us to successfully roll out a teamsite content management product. Therefore, we have to see if it will work before we go committing any other resources to the development of the product.

Content Management

Tue, 21 Jan 2003 21:54:30 GMT

<%radio.macros.imageref ("/images/scrat.jpg")%>

I have a tough nut to crack, and that nut is content management. I feel like Scrat, the rodent in the movie Ice Age who has such a hard time getting a meal. ITS has not made friends with people over the way the development of a content management product has been executed. I came into the picture well past midway, at least from a project momentum perspective. Before leaving last month I was working on a business case for the product, which I partially completed. My approach to the business case did not take into account all factors that should affect that decision, so I am revisiting it now.

In order for Teamsite to be successful, it needs to provide a favorable cost to benefit ratio to our customers, meaning that it should provide a benefit that exceeds cost. Each of the following factors would determine if that is possible:

Front Office must be implemented successfully. Using templates with Teamsite is difficult, and the training necessary to support it is heavy. Front Office allows the user to submit content from a standard office suite product, such as MS Word.
The cost incurred by an agency to set up a Teamsite content management solution must be recovered in decreased site admin costs within a reasonably short period of time (6 months? shorter?).
The thing has got to be relatively easy to manage from an agency perspective. Changes to their Teamsite configuration, including deployment information, should be easily changable.
Training can't be too heavy. Content contributors should be flying in a short amount of time with little cost.
The thing has to be available ASAP.
ITS must be able to provide adequate levels of customer support to reduce the burden on agencies. ITS must be committed to it as a product, and to supporting the customers who use it.
Of course, the price point must be affordable to agencies.

Like I said, a tough nut to crack. I will be meeting with agencies to get their perspective over the next couple of weeks. I welcome your comments or suggestions.