Positions, positions and more positions.

First of all, let me note for the record, we are not in a position to hire anyone. We have no financial support from the industry and expect no one to have to incur any risk in the development of these systems. There are times when writing this blog seems like I have become completely delusional, this is one of those posts. The purpose in mentioning these positions is to provide the readers of this blog with an understanding of where and how they may be able to fit into the developments, when they are funded.

In past blog entries we have been able to list a small number of positions that are involved in the development of the application. These previously noted positions are as follows.

Product Owner

When we begin development, we will be looking for these somewhat new and interesting positions. With the number of development teams approaching the low twenties, each with their own Product Owners, we will be looking for a large number of people to fill these positions.

In a previous blog post, we documented some of the work that is carried out by Product Owners.

Account Manager

A little bit of chaos never hurt anyone. Too much chaos and we run the risk of disrupting the communities involved in this development. That’s what the Account Manager position is designed to deal with. Ideally these people are seconded from the producer firms that they will represent as an Account Manager. In a previous blog post, we documented the work of the Account Manager.

Agile Team Business Analyst

We highlighted the Agile Team Business Analyst position in another recent blog post.

We also have the following executive positions available, when we are funded that is.

Chief Financial Officer

As all good firms have, financial management is an inherent part of success. As someone who has been a CFO, I have a strong perspective on the position. The CFO of any firm has to be the one that is ultimately responsible for the financial success. And they have the power necessary to make this so.

A difficult task of this position will be the compensation provided to the Community of Independent Service Providers. That is to say with so many participants in the development and the CISP, managing the work flow of these communities will be an important aspect of the success of this position.

Chief Operating Officer

Keeping all the balls in the air is the skill that these people provide their firms. COO’s have the ability to anticipate the needs of the organization and prepare the way for the smooth implementation of those capabilities.

Vice-President Development

Heading the software development effort of People, Ideas & Objects will be the responsibility of this position. From managing the “Agile” development team, which is expected to grow to 300 developers, to maintaining the development tools. This position is responsible for anything and everything to do with the software.

Since we are an Oracle customer, this person will need to be well versed in those technologies. Recall that our strategy regarding Oracle is that we use their technologies from stem to stern. It would therefore be incumbent on this position to use the Oracle resources to the utmost. Having a large team of Oracle developers and consultants would therefore be expected to be employed by the Vice-President Development of People, Ideas & Objects.

Vice-President Community Development

Working with the resources as presented by the Community of Independent Service Providers. This person will need to ensure the CISP develops in the best interests of the innovative oil and gas producers. The Account Manager positions noted earlier in this post will also report to the Vice President Community Development. Therefore there will be a large emphasis on policies and procedures to ensure these large populations of people are prepared, motivated and capable of meeting the demands of the innovative producers.

Vice-President Business Development

We are committed to the oil and gas industry as software developers. We are not, and will not entertain the thinking that we can provide service to other industries. With this in mind, the Vice-President Business Development is seen more as a resource that is available to the executive team. Added bench strength in areas of issues and opportunities will serve the firm and the innovative oil and gas producers well.

Vice-President Infrastructure. 

I had previously detailed the hardware policies and procedures of People, Ideas & Objects. The oil and gas industry is expected to provide the individual to head the hardware infrastructure to run the People, Ideas & Objects software applications. This is done to ensure they have the means to have their applications run in a manner that is consistent with their compliance and governance needs.

The president of the hardware firm is also the Vice-President Infrastructure for People, Ideas & Objects. As a member of the team this individual will have to have an intimate understanding of the software and its needs.

Director Research

When you look at the organizational chart in this post. The position of Vice-President of Research is held by myself. The Director Research position therefore needs to be capable of working with me to guide the firm on its long term path.

Members of the Community of Independent Service Providers

And one’s imagination is the only limit to the types of work that can be done as a member of the Community of Independent Service Providers.

One of the attributes of the work at People, Ideas & Objects is the range and scope of understanding. We need to know the business of the oil and gas industry, the advanced hardware and software technologies and the academic sciences of organizational economics as well as other disciplines. A very challenging and rewarding group of positions in these fast paced times.

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 Business-Analyst Account-Manager Community Product-Owner Organization

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