The Product Owner in our Leadership Team Part III

We have been discussing the Product Owner position in detail this past week. This position is a key part of our leadership team that we are currently recruiting. If you have an interest in the Product Owner position for one of our modules or technologies please contact me below. In the last post we discussed the Leader and Team Player attributes of the position. Today we continue with several other attributes of the Product Owner. Quotations are from the book “Agile Product Management with Scrum: Creating Products that Customers Love” by Roman Pichler.

People, Ideas & Objects state that we are filling a “gap” between the oil and gas, and Information Technology industries. Creating a sub-industry where nothing exists today. This “gap” exists as the technologies have become too specialized and as a result technology firms are unable to fully understand the needs of its customers, the oil and gas firms. What we are doing in filling this “gap” is providing a means of communication between the oil and gas and Information Technology industries so that they operate more effectively. In the book Roman Pichler states that the Product Owner is an effective communicator and negotiator that operates to “communicate with and aligns different parties, including customers, users, development and engineering, marketing, sales, service, operations, and management. The Product Owner is the voice of the customer, communicating customer needs and requirements and bridging the gap between ‘the suits’ and ‘the techies.’” It is this role as communicator and negotiator that we are placing so much emphasis on the Product Owner role within our leadership team of the user community.

The next two attributes that an effective Product Owner requires are to be empowered and committed. The ability to present new projects for development, and the ability to cancel poorly performing ones are necessary for the continuous improvement of the modules. The Product Owner also needs to have budgetary control of the module they are responsible for. These attributes impute a senior level of responsibility, especially considering the size of the user community budget for each module. Therefore an executive level of commitment is expected in return and as the book states “A successful Product Owner is confident, enthusiastic, energetic, and trustworthy.”

The physical location of the Product Owners matters. Our development team will be based in Houston. Therefore the Product Owners will be based in Houston. The need to have the Product Owners interact with the development team for their individual modules on a regular basis is a necessity. And this requirement would mean a minimum of two days per week. The offices of the Product Owners and user community resources will be located with the development team, therefore this will not be an issue.

Another key role in the development team is what is called the ScrumMaster. “The ScrumMaster supports the Product Owner and the development team, protects the team and the process, and intervenes appropriately when required to ensure that the pace of work is sustainable, that the team stays healthy and motivated, and that no technical debt is incurred.” And “The Product Owner is primarily responsible for the “what” -- creating the right product. The ScrumMaster is primarily responsible for the “how” -- using Scrum the right way. Only when the right product is created with the right process is enduring success achieved.”

The Preliminary Specification and user community provides the oil and gas producer with the most dynamic, innovative and profitable means of oil and gas operations. People, Ideas & Objects Revenue Model specifies the means in which investors can participate in these user defined software developments. Users are welcome to join me here. Together we can begin to meet the future demands for energy. And don't forget to join our network on Twitter @piobiz anyone can contact me at 403-200-2302 or email here. 

Scope of the Preliminary Specification

We have therefore established January 1, 2011 as the commencement of the development of the Preliminary Specification. What does this involve and what are the objectives of the specification? This post will provide a general outline of the work that will be done during 2011.

Firstly we should establish what a “collaboration” is. In many instances the terms collaboration and consensus get confused. I see these as two distinctly separate terms. What I feel happens is a group will define what a consensus is by determining what the majority will agree to. On the other hand, a collaboration is the hard work of determining what is the optimal solution. Collaboration is a process that achieves breakthroughs and discoveries.

The Preliminary Specification is a consensus of the producer community. It is important to have the input of subscribing producers to define the overall scope of the application. If a producer has operations in the Gulf of Mexico, extensive NGL or heavy oil operations they should ensure that the Preliminary Specification’s scope captures those requirements. If they don’t actively participate to define their needs within the application, at the commencement of this development, it will be significantly more difficult to assert their needs in subsequent iterations of the development.

The Preliminary Specification is a collaboration of the end user community. These are the people who will need to use the application. They are the best resource to define the application process and functionality that they need to do their jobs. It is their tacit knowledge that is and will be employed in the oil and gas industry. Tacit knowledge can not be captured and employed by computer systems. What users can do is build the software tools they need to deploy their tacit knowledge. Collaborating to define and discover what tools would work best is therefore their responsibility. No one else can do this critical definition for the user community.

The Preliminary Specification is a collaboration of the Community of Independent Service Providers (CISP). This group of individuals, teams and firms are the glue that holds the developers and the users together. They are resources that provide the users with the delivery of their software tools.

The Preliminary Specification has been previously defined as 100 People years of effort. The population of users, producers and CISP participants in making up this 100 People years is very large. In the several thousands. The larger the participation, the better the output of the specification will be. In essence we are trying to capture as many of the ideas that are available in the various communities, the needs of the producers, determining which are the breakthrough discoveries and settling on a scope of functionality of the application. A quotation of Version One defines this as breadth of the application.

To effectively deal with scope on an Agile project, specifications must be considered in two dimensions: breadth first and then depth. It is essential that we understand the breadth of what we want to build early in the project. Dealing with the breadth of the solution helps the team understand scope and cost and will facilitate estimating and release planning. The breadth of a project begins to frame the boundaries of the project and helps to manage the organization’s expectations. Looking at the breadth of the requirements is a much smaller investment of time and resources than dealing with the entire depth. The details are most likely to evolve as we progress through the project so defining them early has less value.

The two constraints placed on the Preliminary Specification are they must use the Draft Specification as it's starting point and be focused exclusively on the business of oil and gas. Technology is not part of this specifications deliverable. The depth of the application will be determined during the Detailed Specification.

Society is put in peril when world oil production declines. There is evidence that the world's oil production has declined. Therefore the world needs to have the energy industry expand its production. To do so requires that we reorganize to enhance the division of labor and specialization within the industry. As has been proven, this reorganization could achieve far greater oil and gas production. Management of the industry is conflicted in expanding the output of the industry. The less they do, the higher the oil and gas prices and the better they appear to perform. This managerial conflict must be addressed and the performance of the industry unleashed. To do so requires the current management of the industry to fund People, Ideas & Objects and build the systems as defined in the Draft Specification. Please join me here.

Technorati Tags: People's Agile-Scrum Budget Collaboration Development Preliminary

McKinsey Conversation with Andrew Gould

Just a quick post today to highlight a McKinsey "conversation with global leaders" Mr. Andrew Gould CEO of oil field supply firm Schlumberger. Of particular interest to me was his discussion of his Research & Development efforts. (Note his M & A groups appear to be part of his R & D.)

We’ve had a separate M&A group. And the M&A group has two functions. The first is normal M&A. But the second is it has a group of technologists within it who just spend their time identifying and following up on small companies. And actually, we have, for the last four or five years, been making step investments into technologies that we think are interesting.

Interesting from the point of view that the head of the largest oil field supply firm is actively acquiring technology groups. This signals to me that the movement to a more innovative footing across the industry is beginning to develop. Add to that this next quotation regarding the complexity shows the opportunity for Schlumberger is clearly identified.

I think that projects are going to get bigger and they’re going to get more complex. They also, to a certain extent, are becoming more remote. In other words, when you see people starting to drill offshore in Greenland, or offshore in New Zealand for that matter, then the remoteness and the logistical complexity and cost of those projects are such that I think the traditional model of procuring each individual service from different vendors and then doing all the integration oneself is going to diminish.

The point of course is that the opportunity for firms, groups and communities of all types in oil and gas are as strong as they ever have been. I have talked about the performance of Agile / Scrum software development teams. As Agile developers we expect to develop software at approximately 500% of the traditional software development methodologies. Schlumberger is experiencing similar performance metrics.

So in China, funnily enough, at the moment our big research-and-development investment is in software. We decided we were too late to go to India. So we built a lab, which is on the campus of Tsinghua University in Beijing. So we basically hire from the two universities, Beijing and Tsinghua. And it’s now at 350 people. The average age is probably about 30. And the creativity and the productivity, the level of productivity, of that lab is incredible. It’s scary. It really is scary.

I mean, we took a program from the US, which was going really badly, and gave it to Beijing. And Beijing’s first reaction was, “You’re trying to kill us, huh? You’re trying to kill this lab.” Then they buckled down and they did it. I mean, it was extraordinary.

and

And I’m afraid it’s something that the West has, you know, not lost, but we better wake up.

Our appeal should be based on these eight "Focused on" priorities and values of how better the oil and gas industry and its operations could be handled. They may not initially be the right way to go, but we are committed to working with the various communities to discover and ensure the right ones are. If your an enlightened producer, an oil and gas director, investor or shareholder, who would be interested in funding these software developments and communities, please follow our Funding Policies & Procedures, and our Hardware Policies & Procedures. If your a government that collects royalties from oil and gas producers, and are concerned about the accuracy of your royalty income, please review our Royalty Policies & Procedures and email me. And if your a potential user of this software, and possibly as a member of the Community of Independent Service Providers, please join us here.

Technorati Tags: People's McKinsey Agile-Scrum Development CISP
 

Oracle Stack - Oracle Fusion Applications

Continuing on with our review of the Oracle product offerings and defining which of their applications and architectures are to be included in the application modules of People, Ideas & Objects. In a previous post, we adopted wholesale the Oracle Database and Middleware product offerings. In another post we noted the Application Integration Architecture and how the Community of Independent Service Providers could use these tools to aid in the accounting integration of a producers system. All of the discussion of the Oracle products and architectures is being aggregated under the Oracle-Stack Label on this blog. Once our review is complete we will be updating the Draft Specification.

Oracle Fusion Applications are a difficult product to commit too since they don't exist as of yet. However, what we can determine from Oracle is that the project is providing the kind of application infrastructure that is necessary to build the Draft Specification and deliver it through the cloud computing paradigm. Oracle Fusion Applications and Middleware are using the best parts of the Agile / Scrum development methodology, and therefore consistent with our approach to development. There are no cultural differences between the Oracle methods and those that were proposed in People, Ideas & Objects developments.

Critical to the success of the Oracle Fusion Applications is their use and application of the Oracle Middleware stack. This is the way that applications are built in most architectures and is consistent with what we were proposing to do before we joined Oracle as a customer. Java Enterprise servers provide the necessary infrastructure and control of information that makes not using a Java Enterprise server, redundant. Recreating the wheel each time a project is started is counter to the Java way.

It is clear in many of the videos and documents that I viewed that the web is the centre of the user experience. All of the application demonstrations and presentations reflected this web centered delivery. Using standard web browsers, Oracle Fusion Middleware and Applications gains this ease of use and universality of access. Making the user experience robust in the cloud computing paradigm. We will need to determine if the web platform provides the level of access control and security necessary to meet our potential producers needs. It is reasonable to assume that if Oracle is using the browser this extensively, they've cracked the security problems and are satisfied with the control. The user having browser access would be a performance and ease-of-use improvement over using Java Web Start, which is the current method defined in the Draft Specification.

One of the key attributes of becoming an Oracle customer is the access to the understanding and knowledge they have in the ERP application market-space. Oracle is the largest enterprise software company. They have experience in developing, deploying and supporting their ERP application offerings. This experience is based on a history of PeopleSoft, J.D. Edwards, Siebel , BEA and Oracle Financials. Our costs may be substantially higher by using Oracle, but what we gain in doing so brings our product offering to a higher level of quality. According to videos that I viewed on YouTube Oracle has over 2,500 application developers just in the Fusion Applications development. As a result, we inherit the efforts of these people through the Java re-use attributes.

To view one of the best documents on Oracle Fusion Applications go here. Where on page five the following is noted.

The goal of Oracle Fusion Applications is to help customers transform their business into a next generation organization. This next-generation organization will have more adaptable business processes, more productive people, and more manageable systems. Next generation adaptability will come from a native service oriented architecture that allows for easier integration with other applications and configurable business processes. Embedded business intelligence, a rich, pervasive, and personalized user experience, and Enterprise 2.0 business processes will power next generation productivity. Finally centralized security, audit, and controls, and the ability to deploy applications on premise, as a service, or through business process outsourcing will deliver next generation manageability.

This quotation shows that Oracle and People, Ideas & Objects are wholly consistent in terms of our approach to defining and supporting the software for the innovative oil and gas producer. Therefore, the commitment to these products and architectures is made quite easily.

Next on this topic we'll review the Oracle Consulting offerings. Our appeal should be based on these eight "Focused on" priorities and values of how better the oil and gas industry and its operations could be handled. They may not initially be the right way to go, but we are committed to working with the various communities to discover and ensure the right ones are. If your an enlightened producer, an oil and gas director, investor or shareholder, who would be interested in funding these software developments and communities, please follow our Funding Policies & Procedures, and our Hardware Policies & Procedures. If your a government that collects royalties from oil and gas producers, and are concerned about the accuracy of your royalty income, please review our Royalty Policies & Procedures and email me. And if your a potential user of this software, and possibly as a member of the Community of Independent Service Providers, please join us here.

Technorati Tags: People's Oracle Oracle-Stack Specification Agile-Scrum Development
 

Focused on the Product

Continuing on with our review of the eight focus areas of this project. Today I want to highlight the key benefits around the actual software application. These focus areas are compiled from our first quarter's, 30 compelling reasons that People, Ideas & Objects should be funded and developed.

The Product

People, Ideas & Objects is a customer of Oracle Corporations products. With the acquisition of Sun Microsystems, Oracle now provides the hardware and software that we will use in building and providing our software solution to the oil and gas marketplace. In the past number of years Oracle has spent greater then $39 billion in research and acquisitions to make their products the best in the marketplace. With the closing of the Sun Microsystems acquisition, Oracle's offering is now in place and will be used to develop the People, Ideas & Objects application modules and deliver the solution in the cloud computing paradigm.

Today there is also a revolution in terms of the performance of software developers. Agile / Scrum / Lean based software development methodologies are enhancing team performance by metrics of 500 to 1,000 percent. Impressive yes, but more importantly they are eliminating the issues of waste in terms of the excessive cost, chronic lateness and off specification types of issues that have plagued software development for decades. This isn't the end of the problems in software development, just the first of many steps in making the customer focus the primary concern.

One of the many things that we have learned in this blog, and seem to be discovering from many different perspectives. Is that tacit knowledge, the collective understanding held by the users in the oil and gas industry, drives software definition. To preclude the user from the developments would preclude success, literally. Tacit knowledge can't be captured. The user has to have the tools developed to enable them to use their tacit knowledge in the most effective manner. That is the product focus of People, Ideas & Objects.

People, Ideas & Objects, although not a "pure" Open Source project provides the innovative oil and gas producer with open access to the software code that makes up the application. This provides the producer with access to the software code to ensure the application is performing as it should. I foresee the energy industry hiring a member of the CISP to verify the software code for audit and other purposes. This "openness" ensures that the use of the software is consistent with the needs of the innovative oil and gas producer.

Normally I would include the Costs associated with this development as part of the Product Focus. Although our total costs are high, early projections for development of the Draft Specification are in the range of $800 to $1 billion. These costs are allocated based on a low dollar per barrel of oil equivalent per year basis. (Just $1.00 per boe / year for 2010, potentially generating $10 million in the U.S. alone.) Making subscribing producers total ERP costs a small percentage of what those firms pay today. Importantly, as we are learning in our review of Alfred D. Chandler, "Strategy follows Structure". By using the Joint Operating Committee as the key organizational construct of the innovative oil and gas producer. People, Ideas & Objects enable the producer to focus on their key competitive advantages, the development and application of their earth science and engineering capabilities to their asset base.

Lastly I want to point out that the Apple iPad was released this past weekend. I think the product is a major turning point in the use of technology in business. Chaining one's self down to a desk became all the more ridiculous as a result of Apple's iPad. The ability to conduct your business anywhere and at anytime is now very real. Those producers who subscribe to People, Ideas & Objects will have direct benefit of products such as this. I recently noted some of the innovative ways that we intend to develop to these types of platforms, and have already documented some of the advantages of working with that platform.

If your an enlightened producer, an oil and gas director, investor or shareholder, who would be interested in funding these software developments and communities, please follow our Funding Policies & Procedures, and our Hardware Policies & Procedures. If your a government that collects royalties from oil and gas producers, and are concerned about the accuracy of your royalty income, please review our Royalty Policies & Procedures and email me. And if your a potential user of this software, and possibly as a member of the Community of Independent Service Providers, please join us here.

Technorati Tags: People's Focus Oracle Development Funding Agile-Scrum
 

Agile Teams - Business Analyst Position

Version One provides software for agile development teams. We have, and will continue to highlight a series of .pdf's they publish to help describe the various roles and responsibilities of agile team members. These are contained in blog posts here, here and under the Agile-Scrum label. Today we are highlighting another position thanks to Version One's .pdf "The Agile Business Analyst". [Note the link takes you to a page where you can request downloads of all their .pdf's.]

How many Business Analysts positions will be on People, Ideas & Objects twenty development teams depends on a number of factors that can't be determined at this time. There are however, many things that we can learn about the agile methodology and the work that will be done on those teams by reviewing all of Version One's .pdf's. So what is a Business Analyst on an Agile development team.

Agile development is having a significant impact on the Business Analyst community. Agile introduces a significant shift in how teams look at requirements and when they are defined in the process. Agile Business Analysts are an integrated part of the team throughout the life of the project and facilitate collaboration across a broader cross section of the project team and the business.

and

Collaboration, facilitation, leadership, coaching, and team building become significant new skills required for Business Analysts on Agile projects. Leadership and collaboration are key components critical to their success.

Gone are some inherent assumptions about the Business Analyst. The following list shows the difficulty in the position as has been defined in previous software development methodologies.

• Assumes that the customer can definitively know, articulate, and functionally define what the system or software should do at the end of the project
• Assumes that, once documented, the requirements will not change – at least not without potential project delays, budget overruns, or stunted feature sets
• Assumes that the requirements process is confined to a single product owner who sits apart from the development team envisioning the product
• Does not acknowledge the inherent uncertainty in software development that Agile methodologies seek to embrace

These four items are flawed from the outset. The agile team can not make these types of assumptions. It is certainly beyond the scope of reasonableness to assume that the Business Analysts can deal with this much ambiguity. Recall our recent blog post entitled "Designed to hit a moving target" that highlights a 47 minute presentation of the Agile Software Development Methodology. Version One then summarizes Agile Project Management in terms of what is possible.

Agile Project Management assumes that the processes required to create high-value working software in today’s economy are not predictable: requirements change, technologies change, and individual team member productivity is highly variable. When processes are not static and outcomes cannot be predicted within sufficient tolerance, we cannot use planning techniques that rely on predictability. Instead, we need to adjust the processes and guide them to create our desired outcomes. Agile project management does this by keeping progress highly visible, frequently inspecting project outcomes, and maintaining an ability to adapt as necessary to changing circumstances.

People, Ideas & Objects Draft Specification seeks to provide an overall vision of how the application would define and support the innovative oil and gas producer. This vision is the key input of the Preliminary Specification. This next quotation from Version One accurately captures what I think is a necessary deliverable from the Preliminary Specification.

To effectively deal with scope on an Agile project, specifications must be considered in two dimensions: breadth first and then depth. It is essential that we understand the breadth of what we want to build early in the project. Dealing with the breadth of the solution helps the team understand scope and cost and will facilitate estimating and release planning. The breadth of a project begins to frame the boundaries of the project and helps to manage the organization’s expectations. Looking at the breadth of the requirements is a much smaller investment of time and resources than dealing with the entire depth. The details are most likely to evolve as we progress through the project so defining them early has less value.

The Draft Specification is the vision, the Preliminary Specification is the breadth and the Detailed Specification is the depth. It's almost like we knew what we were doing! But seriously, the breadth of the application is of key concern to the producers in the oil and gas industry. If you want the application to mirror accurately what your organization should look like, then participation is mandatory. Participation requires that the producer firm fund these developments, and secondly get involved in these developments and help to define the breadth of the application within the Preliminary and Detailed Specifications.

Having a solid understanding of the breadth of project requirements early in the life-cycle helps the development team begin to define the set of possible solutions. The Business Analyst plays a key role facilitating the conversation between the product owner, executives, the technical team, and the QA team. The BA is a key player in ensuring that the full scope of requirements has been defined and balanced by an overall technical understanding of the solution.

The Business Analyst Position begins to have a significant impact on the quality of the developments from this point forward, the Detailed Specification.

Once the team has established the breadth of the solution, it is time to begin incrementally looking at the depth of the solution. The BA will typically take the lead helping the team bring the requirements down to this next level of detail. To incrementally look at the depth of the requirements, we have to abandon our traditional notions of the Marketing Requirements Document (MRD), Product Requirements Document (PRD) and the list of “the system shall” specifications. Instead, we focus on how the system is going to behave.

and

Much like the Agile Project Manager, the Agile Business Analyst will rely much more on people facilitation skills than they may have on traditional projects. The BA’s role is to facilitate a discussion between the product owner and the technical team. The BA will typically bring a tremendous amount of system knowledge to the discussion and is well positioned to draw out functional requirements from the product owner. BAs can also help translate user needs into more technical language for the developers.

People, Ideas & Objects assumes that the energy producer is organizationally constrained. The organizational ability to keep pace with the underlying changes in the earth science and engineering disciplines needs to be purpose built through the vision of the Draft Specification and this software development methodology. To suggest otherwise assumes that we have the time to contemplate alternatives, or to continue to muddle through. As is stated in Version One's conclusion to the Business Analyst Position, that is not an option.

Success in today’s economy requires us to respond quickly to changing market conditions. Traditional product delivery methodologies cannot deliver fast enough in highly uncertain project domains. Agile processes allow teams to meet the changing demands of their customers while creating environments where team members want to work.

March 31, 2010 is the deadline for raising our 2010 operating budget. After which a variety of consequences, such as financial penalties and a loss of one years time will occur. Our appeal should be based on the 30 compelling reasons of how better the oil and gas industry and its operations could be handled. They may not be the right way to go, but we are committed to working with the various communities to discover and ensure the right ones are.

If your an enlightened producer, an oil and gas director, investor or shareholder, who would be interested in funding these software developments and communities, please follow our Funding Policies & Procedures, and our Hardware Policies & Procedures. If your a government that collects royalties from oil and gas producers, and are concerned about the accuracy of your royalty income, please review our Royalty Policies & Procedures and email me. And if your a potential user of this software, and possibly as a member of the Community of Independent Service Providers, please join us here.

Technorati Tags: People's Agile-Scrum Development Business-Analyst
 

Designed to hit a moving target

People, Ideas & Objects is an Agile software development developer. I've come upon a slide presentation that documents many of the key attributes of the Agile software development methodology. It's a 47 minute presentation that provides people with an understanding why the Agile processes are superior to past software development methodologies. The title of this entry captures accurately why Agile works.

Instead of repeating what is stated in the presentation, it would be better to explain how the Agile process will be implemented in People, Ideas & Objects. A key difference is the collocation of the teams for development. People, Ideas & Objects have the following policies regarding collocation.

Physical location is irrelevant. Particularly as Integrated Development Environments (IDE's) like NetBeans and Eclipse have tools to aid in developer communications. This collaborative area of IDE development has only begun and I expect to see many tools for the Agile teams collaborations to develop.

To access the full scope of the applications user community will require people to be involved from many different regions, many different firms and many different disciplines. If we were to attempt to put everyone under the same roof, we wouldn't get anything done. With the volume of anticipated teams being 20, having 200 developers within one region would be counter-productive from the point of view of user input. Working virtually is key to the success of this project.

Generally, it should be considered that a team be within the same time zones. Are dedicated full time to the development of their People, Ideas & Objects modules, and have access to users. Exceptions to this will occur, particularly as we wish to access teams in India and other regions. If collocation becomes an issue to the performance of the team, then we can "tune" the team by bringing them to one location for a two week period to work out the performance related issues.

Access to developers. To developers the tools they use are the same irrespective of where they are. If they are collocated within the same offices as the other team members, or across the country, it does not matter, in my opinion. What does matter is access to quality developers. If we were limited to acquiring the developers from just one city, it would constrain us in terms of our demands for quality software. The energy industry has traditionally not developed a software development capability of the scope that People, Ideas & Objects demands. Therefore to access the talent we need, we will not be putting any physical constraint on the co-location of team members.

As the discussion in the previous paragraph discussed developers, the same can be stated about users and the Community of Independent Service Providers. When do we start? As soon as there is a financial commitment. We'll then settle on the scope of the application, break down the modules into sub-modules and build the user base and software development capabilities.

March 31, 2010 is the deadline for raising our 2010 operating budget. After which a variety of consequences, such as financial penalties and a loss of one years time will occur. Our appeal should be based on the 21 compelling reasons of how better the oil and gas industry and its operations could be handled. They may not be the right way to go, but we are committed to working with the various communities to discover and ensure the right ones are.

If your an enlightened producer, an oil and gas director, investor or shareholder, who would be interested in funding these software developments and communities, please follow our Funding Policies & Procedures, and our Hardware Policies & Procedures. If your a government that collects royalties from oil and gas producers, and are concerned about the accuracy of your royalty income, please review our Royalty Policies & Procedures and email me. And if your a potential user of this software, and possibly as a member of the Community of Independent Service Providers, please join us here.

Technorati Tags: People's Development Agile-Scrum User Policies
 

Product Owner - Position

The Agile / Scrum software development methodology has many predefined roles. The Product Owner is one of them, and Product Owners are a part of the Scrum team. People, Ideas & Objects will have many Product Owners. One for each of 20 possible Scrum teams. [Eleven defined modules of the Draft Specification, User-Interface, Architecture, Data model etc.]

Project Owners are "pigs" in the scrum world. Pigs, unlike Chickens, have everything invested at the breakfast table. An appropriate term in my opinion. Their job is simple, satisfy all stakeholder concerns. Working with the many Account Managers of producers and their users, the Community of Independent Service Providers, (CISP) and their Scrum Team members. Product Owners will be the individuals who magically prioritize the developments to meet the changing needs of the producers.

By adopting Oracle technologies People, Ideas & Objects inherits their entire technology stack. An Open yet integrated technology stack like no other. Making the Draft Specification and subsequent designs executable is no small task, we are grateful for the vision and execution of Oracle Hardware & Software. We are also constrained by those technologies, and it will be the Product Owners that feel those constraints the most.

By adopting Oracle we will have an advanced tool set and infrastructure to deal with. Our developers and particularly our Product Owners will have to be intimately familiar with Oracle technologies. This is the standard means of Oracle application delivery in the marketplace. There is a substantial marketplace of Oracle consultants available to People, Ideas & Objects and associated communities. In addition to the need to be familiar with the Oracle technology stack, Product Owners will need to be intimately familiar with the oil and gas industry, generic business needs and their "products". I'm just glad I already have a job at People, Ideas & Objects.

By way of a scenario, as the Product Owner of the Petroleum Lease Marketplace (PLM) Module a day might look similar to this... The Product Owner reviews a small sample of email messages, and prior days edits to the wiki. Edits and comments from the 500 Account Managers and 27,000 users who use the PLM. Account Managers are at times representative of the collective desires of these 27,000 users. These users have compiled a wish list of 1,000 user stories of what they need and want in the PLM software. Although daunting, the solutions to each can be represented by making 15 major changes in the PLM. The Product Owner has been blogging about these 15 proposed changes, for a number of weeks. These changes are also passionately felt by many of the members in the CISP. As always, major changes in the software can be brought into production with one two-week sprint. The Project Owner has recruited a representative group of users from 12 producers to work with the developers during that sprint. The Product Owner sets tomorrow for the team to begin these developments. Suddenly she realizes it's 7:30 in the morning and she has to get ready to catch a flight to Europe for the bi-annual People, Ideas & Objects user conference...

A little creative license is handy. If your an enlightened producer, an oil and gas investor or shareholder, who would be interested in funding these software developments and communities, please follow our Funding Policies & Procedures, and our Hardware Policies & Procedures. If your a government that collects royalties from oil and gas producers, and are concerned about the accuracy of your royalty income, please review our Royalty Policies & Procedures and email me. And if your a potential user of this software, and possibly as a member of the Community of Independent Service Providers, please join us here.

Technorati Tags: People's Project-Owner Passion Oracle PLM Development CISP Agile-Scrum
 

One plus One Equals Five

That's not just bad math, that's the new Oracle / Sun merger. Wow. I have always appreciated both companies for their technical abilities. They have always worked together to bring these excellent technologies of theirs, however, there was always a bit of a break or a seam between the two companies where things would fall through the cracks. Now there is one provider for all the technologies and the gaps are filled. But that's not all. When you add the two, the sum of the parts is clearly much larger then the two companies parts.

I am revisiting our strategy regarding the technologies that are being offered by Oracle / Sun. I have been critical and maybe a bit unkind towards Oracle and maybe now we need to re-evaluate that. What is different to me is that we don't fit into the Oracle developer world. I see People, Ideas & Objects as a customer of Oracle / Sun. When I see things from that renewed perspective, I see this solution growing substantially more real in terms of its possibilities.

Making this big of a shift in terms of the Draft Specification, the user community and the Community of Independent Service Providers are not affected. Producers win handsomely in a revised People, Ideas & Objects. I'll be making this decision in a short period of time. January 31, 2010 I'll note the changes, if any, in a post.

Larry Ellison made the comment in his presentation today. "How can you be against cloud computing, that's all there is". Sun Microsystems wrote a White Paper on Cloud Computing in June 2009. Access to the document may require registration. Unlike most papers on Cloud Computing, this paper identifies the key concepts and concerns of business users. I learned a lot about many of the changes in architecture that are necessary, and I see clearly how an application such as People, Ideas & Objects can run in the cloud.

The two terms best used to define People, Ideas & Objects overall concerns is "Quality & Velocity". Two buzzwords that are well worn but important to these communities. Quality of course is the hard fought-for demand for perfection. Doing things in a half-baked manner is unacceptable to me and these user communities, and although I am unable to assert the necessary requirements in a project with this scope. The architecture and Complex Adaptive Systems, where users are in control of the product quality, are how the People, Ideas & Objects application modules will achieve its quality.

Velocity is a term that is being used in the technology and Complex Adaptive Systems communities. It refers to the speed at which things are happening. The bureaucracy was very effective in its efficiency, due to its inherent inefficiency. That is to say that the bureaucracy is inefficiently efficient. Today, and in the future, requires that velocity be accelerated to meet the demands of the market for energy. Velocity is the speed of change and development, and can not be planned or organized in a traditional fashion. It has to happen and evolve from the community naturally, it can't be forced or involve management changes.

Quality & Velocity are why the communities, and particularly the Community of Independent Service Providers are so important to the success of People, Ideas & Objects and the energy industry. As much as I want to be part of that community, I know that any further meddling from me is not just counter-productive but destructive. If I could write the Preliminary Specification it would take me 5,000 years. I chose the alternative and sane choice of not being involved at all. My job, as I see it today, is to source the financial resources to support the communities and, hopefully I will be able to continue to do research in areas that may be of value to the communities. When I mean communities I mean everyone that is affected by these developments.   

Cloud computing imposes some interesting restrictions on our developments, and some interesting opportunities. The biggest opportunity is of course facilitating velocity. Recall in the shrink-wrap days how software was upgraded? Usually annually and with a steep price attached. People, Ideas & Objects will be upgraded constantly, possibly by the second. There is no way that I can see an industry such as oil and gas, with the inherent issues ahead of them being able to adapt quick enough if they are not using cloud computing for their ERP system. SAP is the bureaucracy, as is People, Ideas & Objects are the nimble, agile and high velocity oil and gas industry.

One very interesting change from traditional systems is the stateless nature of cloud computing. If we go back to our Technical Vision, we see that Asynchronous Process Management is a cornerstone of our application. This means that when partners in a Joint Operating Committee vote for a capital expansion, this may bring in elements of game theory. Therefore some producers may withhold their vote until they can determine another firms decision. This is asynchronous in that the voting process may be held up for a few weeks. This asynchronous process will have to be written to new tables in the database to reflect its percent of process completion. Not a difficult thing to do, but to leave the variables in state could lead to technical difficulties in the Cloud computing model and potentially lost data. Its an architectural change in the way that cloud computing operates.

I can see in my future many oil and gas company managers arguing that their involvement in this critical area should be considered, and a different architecture be adopted. If we go back to Professor Carlota Perez, the People, Ideas & Objects strategies are the competitive way in which the Information & Communication Technology Revolution competes with managements charade. Management have a choice, either accept the changes that are happening or die. I, after six years have a preference towards your demise, however I won't state it here, their may be children that are reading this.

Again this Sun Microsystems paper is by far the best that I have seen on the concepts around cloud computing. It fits into how the oil and gas industry is able to accelerate its performance to the level that is needed to meet the market demand for energy. Meeting these demands for the remainder of this century. If your an investor or shareholder in oil and gas that thinks this alternative form of organization meets with your needs. Please review our Funding Policies & Procedures. And if your a potential member of our user community or interested in the Community of Independent Service Providers, please join us here.

P. S  I am impressed by Apple's new iPad. The only question I have about the device, is what do you need an office for?

Technorati Tags: People's Oracle Sun Agile-Scrum Strategy
 

Complex Adaptive Systems

Today I'm opening a new line of research in this blog. We are now turning the corner and beginning the process of becoming an organization that builds the application defined in the Draft Specification. Back as far as May 2004, in the Preliminary Research Report, self-organizing teams have been part of this software development project. Not just the software developers, the self-organizing and adaptive team concepts are being applied to the User groups and the Community of Independent Service Providers. With this post I'll begin aggregating this research on the "Agile / Scrum" Technorati Tag, and Label.

Why do we want to do this? I am of the belief that the software code that defines and supports the innovative oil and gas producer will never be static. Constant change and improvement are a necessary underlying requirement of supporting the earth science and engineering capabilities of the oil and gas producer. A producer may discover through using the many Marketplace modules; other ways of doing things that are more effective. Just because this new method may be a 10 fold increase in the way things were done before, doesn't mean that another doubling isn't just around the corner. A committed software developer and user community is a cornerstone of the innovative oil and gas producer, and what People, Ideas & Objects is structured to achieve.

Another reason we are doing "Complex Adaptive Systems" (CAS) is the fact that the scope and scale of the application modules is beyond what can be achieved in the traditional ways of organization. Add to that the demands of the energy marketplace will soon outstrip what the producers can deliver. There will soon be the need for an acceleration in performance of the oil and gas industry, that is multiples of today's performance. If engineering and earth sciences required $1.00 per barrel of oil in 1997 they may need $15.00 today and $40 in the very near future. Much of this may be solved through faster computers, the point is weather your using a slide rule or a supercomputer the volume of engineering, and earth sciences is fixed and growing, logarithmically.

We see today's pricing of oil and gas supports this growing technical requirement. I am not of the opinion that management of oil and gas companies are even concerned about this issue. They have been able to increase revenues and profits for the past 5 years on the basis of doing nothing. Their actions have put us behind the eight ball in terms of delivering this software in a reasonable time frame. It is needed now, and they are all the wealthier by messing things up for the world economy.

Complex Adaptive Systems is a team concept that has enabled the software teams to approach 500% increases in performance, and there will be more in the near future. Applying these concepts to the design and architecture of the Users and CISP will provide similar metrics. And yes, I see the Joint Operating Committee being the Complex Adaptive System that it is. Having an industry operate on these principles is what is required to supply the world with the energy to fulfill what is possible. If your an investor or shareholder in oil and gas and wish to support financially these teams, please join us here. And if your a user that sees this type of application providing the solution to the industry, please join us here.

Technorati Tags: People's Agile-Scrum Development CISP User